|
From: Philippe W. <phi...@sk...> - 2012-11-28 22:57:05
|
Currently, Valgrind does not provide a fully flexible
way to indicate which leak kinds to show,
which leak kinds to consider as an error,
and which leak kinds to suppress.
This is a.o. described in bugs 284540 and 307465.
For example, the current options
(--show-reachable=yes|no --show-possibly-lost=yes|no)
do not allow to indicate that reachable blocks should
be considered as an error.
There is also no way to indicate that possibly lost
blocks are not an error (whatever the value of --show-possibly-lost).
Leak suppression entries are also currently catching all leak kinds.
For example, if you have possibly lost blocks which you want
to suppress, the suppression entry will also suppress
definitely lost blocks allocated at the same stack trace,
thereby hiding/suppressing real leaks.
The patch attached to bug 307465 implements a flexible way to specify
on the command line which leak kinds to show and which
leak kinds to consider as an error.
It also provides a way to have a leak suppression entry
matching only a specific set of leak kinds.
Here are the new command lines args:
--show-leak-kinds=kind1,kind2,.. which leak kinds to show?
[definite,possible]
--errors-for-leak-kinds=kind1,kind2,.. which leak kinds are errors?
[definite,possible]
where kind is one of definite indirect possible reachable all
none
(note: old arguments are kept for backward compatibility).
With the patch, a suppression entry now also has an optional line
indicating which leak kind(s) are matched by this suppression.
For example:
{
<insert_a_suppression_name_here>
Memcheck:Leak
match-leak-kinds: possible
fun:malloc
fun:mk
fun:f
fun:main
}
(where the optional match-leak-kinds: line can specify
leak kinds similarly to the command line options).
When using --gen-suppressions=yes, the match-leak-kinds: line
will be produced to match the reported leak kind.
This is not committed (yet), any feedback about the approach is welcome.
Philippe
|
|
From: David F. <fa...@kd...> - 2012-11-29 07:42:24
|
On Wednesday 28 November 2012 23:56:55 Philippe Waroquiers wrote: > Currently, Valgrind does not provide a fully flexible > way to indicate which leak kinds to show, > which leak kinds to consider as an error, > and which leak kinds to suppress. > This is a.o. described in bugs 284540 and 307465. > > For example, the current options > (--show-reachable=yes|no --show-possibly-lost=yes|no) > do not allow to indicate that reachable blocks should > be considered as an error. > > There is also no way to indicate that possibly lost > blocks are not an error (whatever the value of --show-possibly-lost). > > Leak suppression entries are also currently catching all leak kinds. > For example, if you have possibly lost blocks which you want > to suppress, the suppression entry will also suppress > definitely lost blocks allocated at the same stack trace, > thereby hiding/suppressing real leaks. > > > The patch attached to bug 307465 implements a flexible way to specify > on the command line which leak kinds to show and which > leak kinds to consider as an error. > It also provides a way to have a leak suppression entry > matching only a specific set of leak kinds. > > Here are the new command lines args: > --show-leak-kinds=kind1,kind2,.. which leak kinds to show? > [definite,possible] > --errors-for-leak-kinds=kind1,kind2,.. which leak kinds are errors? > [definite,possible] > where kind is one of definite indirect possible reachable all > none This sounds good, but I'm missing one piece of information: what will the default values be? It would be good for this to have "sane" defaults, so that most users don't actually need to specify these options. Would this mean "show for possible" and "error for definite"? -- David Faure, fa...@kd..., http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 |
|
From: John R. <jr...@bi...> - 2012-11-29 14:24:23
|
On 11/28/2012 02:56 PM, Philippe Waroquiers wrote: > Currently, Valgrind does not provide a fully flexible > way to indicate which leak kinds to show, > which leak kinds to consider as an error, > and which leak kinds to suppress. > This is a.o. described in bugs 284540 and 307465. > Here are the new command lines args: > --show-leak-kinds=kind1,kind2,.. which leak kinds to show? > [definite,possible] > --errors-for-leak-kinds=kind1,kind2,.. which leak kinds are errors? > [definite,possible] > where kind is one of definite indirect possible reachable all > none > > (note: old arguments are kept for backward compatibility). This is good as far as it goes. The presentation in the output from "valgrind --help" will matter, and so will the explanation given in the user manual. Just finding and understanding the new options is a significant barrier to usability. Try to write things so that applying "grep" gives good hints about where to read further. (This may include rewriting _other_ pieces in order to reduce "false positive" usage of key words.) More generally, why isn't this controllable by a loadable Python module, complete with defaults (including a complete default error handling module) and introspection? There should be ways to find all existing suppressions, how many times each one has been applied so far, the current traceback, the "type" of the current error, etc. If coregrind doesn't want to deal with Python, then have gdb do it. -- |
|
From: Philippe W. <phi...@sk...> - 2012-11-29 22:39:12
|
On Thu, 2012-11-29 at 06:25 -0800, John Reiser wrote: > This is good as far as it goes. The presentation in the output from > "valgrind --help" will matter, and so will the explanation given > in the user manual. Just finding and understanding the new options > is a significant barrier to usability. Try to write things so that > applying "grep" gives good hints about where to read further. > (This may include rewriting _other_ pieces in order to reduce > "false positive" usage of key words.) The patch contains the --help and the updates to the manual. Feedback welcome ... > > More generally, why isn't this controllable by a loadable Python module, > complete with defaults (including a complete default error handling module) > and introspection? There should be ways to find > all existing suppressions, how many times each one has been applied > so far, the current traceback, the "type" of the current error, etc. > If coregrind doesn't want to deal with Python, then have gdb do it. Integrate a Python interpreter inside Valgrind seems quite a lot of work. It is not clear to me if the possible usage(s) would justify it. Using the python interpreter in GDB (via the Valgrind gdbsrv) is ok as long as it accesses the "guest process" data. I do not know a way to persuade GDB that the process also has "Valgrind tool" data (and code). Philippe |
|
From: Philippe W. <phi...@sk...> - 2012-11-29 22:35:14
|
On Thu, 2012-11-29 at 08:44 +0100, David Faure wrote: > > Here are the new command lines args: > > --show-leak-kinds=kind1,kind2,.. which leak kinds to show? > > [definite,possible] > > --errors-for-leak-kinds=kind1,kind2,.. which leak kinds are errors? > > [definite,possible] > > where kind is one of definite indirect possible reachable all > > none > > This sounds good, but I'm missing one piece of information: what will the > default values be? The default values are indicated in [] in the --help above. These default values are backward compatible with the current default values. > > It would be good for this to have "sane" defaults, so that most users don't > actually need to specify these options. > Would this mean "show for possible" and "error for definite"? It is expected that keeping the same default behaviour as today is the "sane" default. Philippe |
|
From: David F. <fa...@kd...> - 2012-11-30 11:07:29
|
On Thursday 29 November 2012 23:35:03 Philippe Waroquiers wrote: > On Thu, 2012-11-29 at 08:44 +0100, David Faure wrote: > > > Here are the new command lines args: > > > --show-leak-kinds=kind1,kind2,.. which leak kinds to show? > > > > > > [definite,possible] > > > > > > --errors-for-leak-kinds=kind1,kind2,.. which leak kinds are errors? > > > > > > [definite,possible] > > > > > > where kind is one of definite indirect possible reachable all > > > > > > none > > > > This sounds good, but I'm missing one piece of information: what will the > > default values be? > > The default values are indicated in [] in the --help above. > These default values are backward compatible with the current default > values. Ah, I thought this was the list of possible values in that field. OK. > > It would be good for this to have "sane" defaults, so that most users > > don't > > actually need to specify these options. > > Would this mean "show for possible" and "error for definite"? > > It is expected that keeping the same default behaviour as today > is the "sane" default. I thought this was a good opportunity to improve upon today's behavior and not error for "possible" leaks, only show them. But I'm no expert on the matter. -- David Faure, fa...@kd..., http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 |