Re: [Valgrind-users] Valgrind does leak detection across fork()

[Nicholas N. <nj...@ca...>]

On Sat, 29 Nov 2003 apenwarr@unspecified-domain wrote:

> The attached C program produces the attached valgrind output when run with
> "valgrind --leak-check=yes".
>
> I think valgrind shouldn't bother to do leak checking when a task exits with
> _exit(), since the writer of that program "obviously" didn't intend to clean
> up the subtask properly anyway.  (If you clean up your objects in the child
> task, for example by calling destructors on objects, all heck will generally
> break loose because file descriptors are shared with the parent, who still
> thinks those objects exist.)

I disagree.  There is an important difference between true space leaks,
and memory that you just didn't bother to free ("reachable").  Even
programs that call _exit() shouldn't have true space leaks.  And a few
lines of output showing memory that was reachable doesn't seem like a big
inconvenience.  In this example, Memcheck distinguishes the two cases
exactly how I would want and expect it to.

> My needs would also be met if I could simply tell valgrind to not follow
> forks, since I'm really concerned with grinding my parent task, here.

Not possible with the current design, unfortunately, since Valgrind
becomes part of the process, and so is unavoidably duplicated when the
kernel replicates the process via fork().

N