|
Description
|
Since userland findleaks can run against a running process, caching the results can be confusing.
---
This bug makes some userland debugging tasks very difficult. For example,
I recently want to set a breakpoint in a function, then check for leaks
each time that bp was hit. But this meant that each time I hit the BP I
had to shut down MDB, and restart it in order to get the leak information;
as an example, the following does not work as expected:
> <addr>::bp -c '::findleaks'
Even when the program in question is leaky.
However, mimicking the kernel's behavior for ::findleaks *does* make
sense if the target is a core file. If the target is a running process,
the results should not be cached.
---
The fix for:
4931271 kmem walkers and ::findleaks use large amounts of memory
included a '-f' flag, which will allow a full re-run.
---
We can just clear the cached state in the "State Change" callback needed for
4743353. I'm broadening this bug to cover the kmem module as well; we should
invalidate the leaky state after ':c'ing from kmdb.
|