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

[apenwarr]

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

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.

Suggestions?

Have fun,

Avery

...

The program:

#include <malloc.h>
int main()
{
	void *x = malloc(5);
	if (!fork()) // child
		_exit(0);
	// else, this is the parent
	free(x);
	return 0;
}

...

The valgrind output:

==32117== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==32117== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==32117== Using valgrind-2.0.0, a program supervision framework for x86-linux.
==32117== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==32117== Estimated CPU clock rate is 1209 MHz
==32117== For more details, rerun with: -v
==32117== 
==32121== 
==32121== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==32121== malloc/free: in use at exit: 5 bytes in 1 blocks.
==32121== malloc/free: 1 allocs, 0 frees, 5 bytes allocated.
==32121== For counts of detected errors, rerun with: -v
==32121== searching for pointers to 1 not-freed blocks.
==32117== 
==32117== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==32117== malloc/free: in use at exit: 0 bytes in 0 blocks.
==32117== malloc/free: 1 allocs, 1 frees, 5 bytes allocated.
==32117== For counts of detected errors, rerun with: -v
==32117== No malloc'd blocks -- no leaks are possible.
==32121== checked 3649016 bytes.
==32121== 
==32121== LEAK SUMMARY:
==32121==    definitely lost: 0 bytes in 0 blocks.
==32121==    possibly lost:   0 bytes in 0 blocks.
==32121==    still reachable: 5 bytes in 1 blocks.
==32121==         suppressed: 0 bytes in 0 blocks.
==32121== Reachable blocks (those to which a pointer was found) are not shown.
==32121== To see them, rerun with: --show-reachable=yes
==32121==