Re: [Valgrind-users] some problems with Massif

[Josef W. <Jos...@gm...>]

On Friday 07 March 2008, Nicholas Nethercote wrote:
> 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.

OK, this depends very much on the tool. For profiling tools, clearing
the counters is better option. As the output file name contains the child PID,
the user would not expect that there is data of the parent included, too.
 
> >> 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?

Lost lines in the log file for sure can be a problem? As the child after
fork has the same PID as the new Valgrind process after exec in this child,
the log file name will be the same. Or am I missing something here?

Josef

> 
> > Hmm... does the log file mechanism concatenate existing files?
> 
> No.
> 
> Nick
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>