Re: [Valgrind-users] RFC: more flexible way to show or count as error or suppress leak kinds
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...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 -- Keep yourself connected to Go Parallel: TUNE You got it built. Now make it sing. Tune shows you how. http://goparallel.sourceforge.net ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] RFC: more flexible way to show or count as error or suppress leak kinds
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. -- -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] RFC: more flexible way to show or count as error or suppress leak kinds
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 -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] RFC: more flexible way to show or count as error or suppress leak kinds
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 -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] RFC: more flexible way to show or count as error or suppress leak kinds
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
--
Keep yourself connected to Go Parallel:
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] RFC: more flexible way to show or count as error or suppress leak kinds
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...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
