|
From: Bill H. <bil...@ki...> - 2008-07-01 19:22:15
|
I would like to ping the you folks on this feature request that I submitted: http://bugs.kde.org/show_bug.cgi?id=148932 I use the feature every day, and it is quite useful. Any chance of it getting incorporated into valgrind? Thanks. -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bil...@ki... http://www.kitware.com 518-371-3971 (phone and fax) |
|
From: Bart V. A. <bar...@gm...> - 2008-07-02 16:50:16
|
On Tue, Jul 1, 2008 at 9:21 PM, Bill Hoffman <bil...@ki...> wrote: > > I would like to ping the you folks on this feature request that I submitted: > > http://bugs.kde.org/show_bug.cgi?id=148932 Regarding your patch: are you sure that the construct cited below is foolproof ? + if(VG_(strstr)(VG_(clo_trace_children_skip), (Char*)ARG1)) { + VG_(message)(Vg_UserMsg, "Skip trace child %s %s\n", ARG1, VG_(clo_trace_children_skip)); + VG_(clo_trace_children) = 0; + } Bart. |
|
From: Ashley P. <api...@co...> - 2008-07-02 17:54:26
|
On Tue, 2008-07-01 at 15:21 -0400, Bill Hoffman wrote: > I would like to ping the you folks on this feature request that I submitted: > > http://bugs.kde.org/show_bug.cgi?id=148932 > > I use the feature every day, and it is quite useful. Any chance of it > getting incorporated into valgrind? Wouldn't it make more sense to have a white-list rather than a black-list? Ashley, |
|
From: Bill H. <bil...@ki...> - 2009-01-29 17:14:33
|
Ashley Pittman wrote: > On Tue, 2008-07-01 at 15:21 -0400, Bill Hoffman wrote: >> I would like to ping the you folks on this feature request that I submitted: >> >> http://bugs.kde.org/show_bug.cgi?id=148932 >> >> I use the feature every day, and it is quite useful. Any chance of it >> getting incorporated into valgrind? > > Wouldn't it make more sense to have a white-list rather than a > black-list? > > Ashley, > > 6 months late, but I still would want this patch applied. A white list might be a good idea as well. One or the other would be really great. Any hope of a patch getting into the valgrind soon? Thanks. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bil...@ki... http://www.kitware.com 518-371-3971 (phone and fax) |
|
From: Konstantin S. <kon...@gm...> - 2009-01-29 18:28:19
|
+1 I also have to use a patch similar to this one. Useful feature indeed. Both black and white lists would be good. --kcc On Thu, Jan 29, 2009 at 7:52 PM, Bill Hoffman <bil...@ki...> wrote: > Ashley Pittman wrote: >> On Tue, 2008-07-01 at 15:21 -0400, Bill Hoffman wrote: >>> I would like to ping the you folks on this feature request that I submitted: >>> >>> http://bugs.kde.org/show_bug.cgi?id=148932 >>> >>> I use the feature every day, and it is quite useful. Any chance of it >>> getting incorporated into valgrind? >> >> Wouldn't it make more sense to have a white-list rather than a >> black-list? >> >> Ashley, >> >> > > 6 months late, but I still would want this patch applied. A white list > might be a good idea as well. One or the other would be really great. > Any hope of a patch getting into the valgrind soon? > > Thanks. > > -Bill > > > -- > Bill Hoffman > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > bil...@ki... > http://www.kitware.com > 518-371-3971 (phone and fax) > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Bill H. <bil...@ki...> - 2009-02-11 16:14:55
|
Ashley Pittman wrote: > On Thu, 2009-01-29 at 21:28 +0300, Konstantin Serebryany wrote: >> I also have to use a patch similar to this one. Useful feature indeed. >> Both black and white lists would be good. > > +1 again. > > The real reason for posting however is my email address is changing any > day now so can you drop me from the cc list, my new email is > as...@pi... although I am subscribed to the list anyway. > > I hope to have some free time shortly to scrub up some old patches I > have lying around. > > Ashley Pittman. > > So, what is the process to get this into valgrind proper? -Bill |
|
From: Julian S. <js...@ac...> - 2009-02-14 16:04:39
|
> So, what is the process to get this into valgrind proper?
Two things. First, address Bart's question some days back:
> Regarding your patch: are you sure that the construct cited below is
> foolproof ?
>
> + if(VG_(strstr)(VG_(clo_trace_children_skip), (Char*)ARG1)) {
> + VG_(message)(Vg_UserMsg, "Skip trace child %s %s\n", ARG1,
> VG_(clo_trace_children_skip));
> + VG_(clo_trace_children) = 0;
> + }
I agree with Bart; merely using strstr seems a bit prone to getting
false matches.
Secondly, could you also supply a suitable entry to docs/xml/manual-core.xml,
please? (Look for the string "--trace-children=" in this file, and
copy the varlistentry).
J
|
|
From: Bill H. <bil...@ki...> - 2009-02-16 22:13:13
|
Julian Seward wrote:
>> So, what is the process to get this into valgrind proper?
>
> Two things. First, address Bart's question some days back:
>
>> Regarding your patch: are you sure that the construct cited below is
>> foolproof ?
>>
>> + if(VG_(strstr)(VG_(clo_trace_children_skip), (Char*)ARG1)) {
>> + VG_(message)(Vg_UserMsg, "Skip trace child %s %s\n", ARG1,
>> VG_(clo_trace_children_skip));
>> + VG_(clo_trace_children) = 0;
>> + }
>
> I agree with Bart; merely using strstr seems a bit prone to getting
> false matches.
OK, I will look into a more robust implementation. Is there anything
similar to this already in the valgrind code base that I could look at?
>
> Secondly, could you also supply a suitable entry to docs/xml/manual-core.xml,
> please? (Look for the string "--trace-children=" in this file, and
> copy the varlistentry).
OK, I did not know about that.
Thanks for the feedback. Sounds like if I clean it up a bit, it will
get moved into valgrind proper. I will update the bug when the issues
are addressed.
-Bill
|
|
From: Julian S. <js...@ac...> - 2009-02-18 03:04:03
|
> > I agree with Bart; merely using strstr seems a bit prone to getting > > false matches. > > OK, I will look into a more robust implementation. Good. > Is there anything > similar to this already in the valgrind code base that I could look at? hmm, not sure. maybe the function include/pub_tool_seqmatch.h (?, * matcher) and basic string functions in include/pub_tool_libcbase.h. > Thanks for the feedback. Sounds like if I clean it up a bit, it will > get moved into valgrind proper. I am generally in favour of this functionality -- I think it would be useful -- providing that a suitably robust and general implementation can be arrived at. J |
|
From: Bill H. <bil...@ki...> - 2009-02-19 00:57:16
Attachments:
trace-children-skip.patch
|
Julian Seward wrote: > > I am generally in favour of this functionality -- I think it would be > useful -- providing that a suitably robust and general implementation > can be arrived at. > Attached is a new version of the patch that is more robust and contains the requested documentation. It separates out each , string before doing the compare. -Bill |
|
From: Dan K. <da...@ke...> - 2009-04-14 14:17:38
|
On Wed, Feb 18, 2009 at 2:53 PM, Bill Hoffman <bil...@ki...> wrote: > Attached is a new version of the patch that is more robust and contains the > requested documentation. This would be very handy. I have to jump through hoops to avoid valgrinding python subprocesses at the moment, and this option would have saved me some time. |
|
From: Dan K. <da...@ke...> - 2009-04-19 18:45:01
Attachments:
skip.patch
|
On Tue, Apr 14, 2009 at 7:17 AM, Dan Kegel <da...@ke...> wrote: > On Wed, Feb 18, 2009 at 2:53 PM, Bill Hoffman <bil...@ki...> wrote: >> Attached is a new version of the patch that is more robust and contains the >> requested documentation. > > This would be very handy. I have to jump through hoops > to avoid valgrinding python subprocesses at the > moment, and this option would have saved me > some time. Here's the same patch, updated slightly to apply to svn (it's been dragged through the mud a bit, but I think these are the right bits). - Dan |
|
From: Nicholas N. <n.n...@gm...> - 2009-04-23 05:34:45
|
On Mon, Apr 20, 2009 at 4:44 AM, Dan Kegel <da...@ke...> wrote:
>
> Here's the same patch, updated slightly to apply to svn (it's
> been dragged through the mud a bit, but I think these are
> the right bits).
I think it would be better to separate out the commas at command-line
processing time, rather than later. Alternatively, we could avoid the
commas by allowing the option to be specified multiple times, as is done for
--alloc-fn in Massif.
As for whitelists vs. blacklists, I think whitelists don't make much sense.
For example, if we have this tree of processes:
A --> B --> C
--> D --> C
--> E
Ie:
- A spawns B which spawns C
- A subsequently spawns D which spawns C (the same program as the earlier C,
but a different invocation of it)
- A subsequently spawns E.
We have to trace A. It makes sense to blacklist C, for example. But it
doesn't make sense to whitelist C; in order to trace C we have to trace A,
B and D, and we don't know ahead of time that B and D will spawn C
processes. And if you blacklist something, obviously you won't trace any of
its descendents, (eg. if you blacklist B you won't get the first C).
Another idea is to match not the executable name, but rather the entire
command line, ie. the executable plus the arguments. If we allow wildcards
(which m_seqmatch.c supports) then this can be done easily. I had a case
just this morning where I wanted to skip one 'js' subprocess, but not
another, so an executable-only blacklist wouldn't have sufficed.
Examples:
--skip-children='*' # skip all subprocesses (default)
--skip-children='/usr/bin/python *' # skip all python subprocesses
--skip-children='/usr/bin/python *-v*' # skip all python
subprocesses invoked with -v
--skip-children='' # skip no subprocesses
(equivalent to --trace-children=yes)
(Note that the '*' here is a shell-style wildcard -- this pattern is
not a regular expression. The docs would make that clear.)
If you specify multiple --skip-children options, you'd skip a child if any
of the patterns matched.
With that in place, you don't really need --trace-children any more; you
could make --skip-children='*' the default, and if you specify any
--skip-children options yourself they would clobber the initial
--skip-children='*'. Alternatively, we could make --skip-children='' the
default, and then user-specified ones wouldn't need to clobber... I wonder
if tracing all children is a better default than tracing no children. In my
experience tracing no children is rarely if ever useful.
I suppose for generality it might make sense to blacklist the top process,
eg. "valgrind --trace-children-skip='/home/njn/foo' /home/njn/foo" would run
/home/njn/foo natively. But maybe that's not worth bothering with.
Anyway, for those of you who've made it far, congratulations. I'll work on
a patch implementing this more powerful version.
Nick
|
|
From: Julian S. <js...@ac...> - 2009-04-23 09:41:48
|
Some possibly disjointed comments:
> I think it would be better to separate out the commas at command-line
> processing time, rather than later.
Agree.
> Another idea is to match not the executable name, but rather the entire
> command line, ie. the executable plus the arguments.
This seems like a much more general solution, yes.
> I wonder
> if tracing all children is a better default than tracing no children.
Euh .. I prefer not to do that. You could wind up tracing
a huge tree of processes unexpectedly, if not careful.
How about this. It gives the kind of flexibility you want, whilst
preserving existing behaviour. (remember the kinds of protestation
we've had in the past w.r.t. changing meaning/behaviour of
command line options)
--trace-children=no retained, and is still the default
--trace-children=yes retained, and behaves as present
--skip-children=<command-line-w-wildcards-as-you-suggest>:
(1) when --trace-children=no or is absent, produces a warning that
--skip-children= is irrelevant when --trace-children=no
(2) --trace-children=yes by itself traces all children
(3) --trace-children=yes together with --skip-children= behaves as
you'd expect.
For (1), an alternative would be to declare --trace-children=no
together with --skip-children= as nonsensical, print an error message
and refuse to start. But that would be a nuisance in the case
where I'm doing some kind of weird experiment, and running with
--trace-children=yes --skip-children=...
and then I temporarily switch to
--trace-children=no --skip-children=...
I just want it to continue with a warning; having to delete a potentially
long list of --skip-children= params just because --trace-children=no
would be a drag.
J
|
|
From: Nicholas N. <n.n...@gm...> - 2009-04-23 22:24:55
|
On Thu, Apr 23, 2009 at 7:43 PM, Julian Seward <js...@ac...> wrote: > >> I wonder >> if tracing all children is a better default than tracing no children. > > Euh .. I prefer not to do that. You could wind up tracing > a huge tree of processes unexpectedly, if not careful. I'm not convinced this is a significant risk. Can you give an example? The most common relevant case I'm aware of is when a script or scripts are used to start up a program. In that case you almost always want to trace the children, because you're not very interested in the scripts. The current behaviour is confusing -- we have a FAQ about it, just today the submitter of bug #188735 hit it, if you don't know about the behaviour it's not clear from Valgrind's behaviour that you're not tracing the children. Even for experts it's easy to get wrong -- I frequently find myself forgetting the --trace-children and having to re-run things. (In fact, you really want a whitelist approach for this. Eg. "valgrind --white-list='/bin/the-real-app *'" which skips all the startup scripts. I realised last night that this could be faked by running Nulgrind (possibly with --quiet) on all the processes that don't match the white-list. Black-lists are still useful -- Dan K mentioned the "skip all Python sub-processes" use case -- so having both would be good, but the interactions would have to be carefully defined.) On the other hand, if we did trace children by default and hit the hypothetical big-tree-of-processes example, at least it's clear what's happening, because you get multiple start-up messages with different PIDs. (If anyone else has relevant use-cases they would encounter, please speak up!) > How about this. It gives the kind of flexibility you want, whilst > preserving existing behaviour. (remember the kinds of protestation > we've had in the past w.r.t. changing meaning/behaviour of > command line options) Yeah, that does make things difficult. Maybe we would deprecate --trace-children, keep it around for one more major release and then kill it. In general I don't like having multiple options that interact, often (as in this case) you can avoid it. Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-04-23 23:12:34
|
---------- Forwarded message ---------- From: Michael Sweet <ms...@ap...> Date: Fri, Apr 24, 2009 at 8:41 AM Subject: Re: [Valgrind-developers] ping on bug report To: Nicholas Nethercote <n.n...@gm...> On Apr 23, 2009, at 3:24 PM, Nicholas Nethercote wrote: ... (If anyone else has relevant use-cases they would encounter, please speak up!) FWIW, the CUPS "make test" target uses --trace-children=yes when running with valgrind specifically so we can test all of the child processes (print filters, generally) in their "native" environment when run from CUPS - we wouldn't run in any other mode. For the rest of the software I've run through valgrind (maybe a couple dozen all together), I can only think of 1 case that I specifically didn't want to trace children - EPM, which runs the corresponding package maker program after creating all of the format-specific support files/directories. ________________________________________ Michael R Sweet, Senior Printing System Engineer |
|
From: Bill H. <bil...@ki...> - 2009-06-22 17:14:55
|
Nicholas Nethercote wrote: > ---------- Forwarded message ---------- > From: Michael Sweet <ms...@ap...> > Date: Fri, Apr 24, 2009 at 8:41 AM > Subject: Re: [Valgrind-developers] ping on bug report > To: Nicholas Nethercote <n.n...@gm...> > > > On Apr 23, 2009, at 3:24 PM, Nicholas Nethercote wrote: > > ... > > (If anyone else has relevant use-cases they would encounter, please speak up!) > > FWIW, the CUPS "make test" target uses --trace-children=yes when > running with valgrind specifically so we can test all of the child > processes (print filters, generally) in their "native" environment > when run from CUPS - we wouldn't run in any other mode. > For the rest of the software I've run through valgrind (maybe a couple > dozen all together), I can only think of 1 case that I specifically > didn't want to trace children - EPM, which runs the corresponding > package maker program after creating all of the format-specific > support files/directories. Just curious as to the status of this? It is very useful to me, but it makes it hard for me to upgrade valgrind as I have to apply the patch each time. Thanks. -Bill |
|
From: Nicholas N. <n.n...@gm...> - 2009-06-24 04:29:53
|
On Tue, Jun 23, 2009 at 2:47 AM, Bill Hoffman<bil...@ki...> wrote: > > Just curious as to the status of this? It is very useful to me, but it > makes it hard for me to upgrade valgrind as I have to apply the patch each > time. I wrote it up and asked for comments: http://blog.mozilla.com/nnethercote/2009/04/30/making-valgrind-easier-to-use-with-multi-process-programs/ There was sufficient lack of consensus in the comments I got that I became discouraged, and Mac OS X support is going to take precedence at least until 3.5.0 is released, which will be in about two months. Sorry. Nick |