|
From: Philippe W. <phi...@sk...> - 2013-10-09 22:32:25
|
On Mon, 2013-10-07 at 21:22 +0200, Matthias Schwarzott wrote:
> Will it work to add some code after the shutdown of our application to
> call into the leaks checker like this to show full leak list and the see
> which blocks disappear by adding one heuristic at a time (copied from
> leak_cpp_interior test):
>
> VALGRIND_DO_LEAK_CHECK; // full list of leaked blocks
> (void) VALGRIND_MONITOR_COMMAND("leak_check changed heuristics
> multipleinheritance");
> (void) VALGRIND_MONITOR_COMMAND("leak_check changed heuristics
> multipleinheritance,newarray");
> (void) VALGRIND_MONITOR_COMMAND("leak_check changed heuristics
> multipleinheritance,newarray,stdstring");
>
> Could the leaks list be changed to show all possible leaks and add the
> information if an heuristic matched it?
> If the performance is too bad, this could be optional.
During the heuristic development, I thought to implement a specific
leak search mode to only report blocks that are reachable via
a selected set of heuristics (and ignore all the other blocks).
Not too difficult, but at the end I found the above commands good enough
to see what changes in a reachable block list when adding/removing
an heuristic.
>
>
> The application also has other kinds of possible leaks that need to be
> supressed.
>
> One of these is the allocation by sqlite3malloc on 32bit platform.
> sqlite3 always allocates 64bits before and stores there the length of
> the remaining block in bytes.
> On a 64bit platform this should be catched by the newarray heuristic I
> think.
>
> Second known possible leak that is no leak is the tls code of pthreads
> (glibc/nptl).
> It calls calloc and later stores a pointer to the second element of the
> array.
> This can be easily done by a supression entry.
Suppressions are for sure the easiest at least for a "single level"
of possibly lost. The advantage with heuristics is that they transform
a possible lost into a reachable, which means that it avoids to have
suppressions for all the indirectly reachable blocks (and related stack
traces).
>
> Maybe valgrind needs some mechanism to specify the allocation function
> and the allowed offset for a pointer.
What we should maybe have is a kind of "leak suppression" which
"transforms" a lost or possibly lost block into a reachable block
(see my other mail, where I suggested even an expression evaluator to
allow the user to define heuristics).
Philippe
|