|
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 |