Thread: Valgrind memory leaks - Dakar or real?

Hi,
I'm trying to figure out a possible memory leak in my C program. I get the following message from valgrind:

16,020 bytes in 1 blocks are still reachable in loss record 1 of 1
at 0x4A04B32: calloc (vg_replace_malloc.c:279)
by 0x38932D57BF: monstartup (in /lib64/libc-2.5.so)
by 0x400B4B: __gmon_start__ (in "my app".o)
by 0x400B6D: (within "my app".o)

LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks.
possibly lost: 0 bytes in 0 blocks.
still reachable: 16,020 bytes in 1 blocks.
suppressed: 0 bytes in 0 blocks.

This doesn't seem to happen with any of "my" memory allocation (none of which are of 16020 bytes). Is this leak "my fault" - is there anything I can do about it? It happens quite randomly - I can try to do the excact same operation several times, and it's a 50-50 chance I'll get this error or "No leaks possible".

Any help would be very much appreciated!


Dakar = false by the way...

Originally Posted by DaleCooper

16,020 bytes in 1 blocks are still reachable in loss record 1 of 1
at 0x4A04B32: calloc (vg_replace_malloc.c:279)
by 0x38932D57BF: monstartup (in /lib64/libc-2.5.so)
by 0x400B4B: __gmon_start__ (in "my app".o)
by 0x400B6D: (within "my app".o)

Are you compiling for profile mode? monstartup() is a function of the C profiling mechanism.

Generally, anything that was allocated by the C library not at your request is not your responsibility. If this particular report bugs you, you can write a suppression rule for it.

Originally Posted by DaleCooper

Thanks, all of you! I've come to the conclusion that it's not my fault I think it must stem from the C library somehow - perhaps it has something to do with the fact that I'm compiling for use with valgrind and ddd (-g -pg options in gcc), if monstart() has to do with profiling?

From the Valgrind FAQ it seems that ""still reachable" means your program is probably ok", so I hope that's correct!

The key is in the full backtrace of the allocation. If you turn the backtrace size way up, to guarantee that you always see a full trace, and you do not see any of your program's functions in the trace, then your program was not responsible for the allocation.

EDIT: The buffer that is being "leaked" is probably the profiling sample buffer.