|
From: Nicholas N. <nj...@cs...> - 2008-03-07 20:04:55
|
On Fri, 7 Mar 2008, Josef Weidendorfer wrote: > On Wednesday 05 March 2008, Nicholas Nethercote wrote: >> ps: Valgrind's main logging mechanism suffers from the same problem, as do >> Cachegrind and Callgrind. The fix is equally simple for Cachegrind and >> Callgrind. > > Yes. > There still is an issue here: you get all the counters happening before > the fork duplicated in the output of the parent and the child. I am not > sure this is the right thing. > It probably would be better to clear the counters in the child directly > after the fork. Maybe -- there's two clear possibilities that make sense. It's unclear to me which is correct. Clearing the counters is more difficult, because it requires the tool to notice it's been forked. >> For the core it's more difficult, because the output doesn't happen all in >> one hit at the end, rather it happens gradually. I guess when a fork >> happens, if we're logging to file and a %p specifier is present in the >> --log-file option, then a new logging file should be opened. Sigh. > > It is even more difficult if the child sometimes afterwards does an exec, > and VG does follow the new executable. Then, the new log file started after > the exec will overwrite the file already written to between fork and exec. Is that a problem? It might be a little inefficient (although the new flag --child-silent-after-fork can help), but I don't see how it would cause a correctness problem? > Hmm... does the log file mechanism concatenate existing files? No. Nick |