Valgrind memory leaks - Dakar or real?

This is a discussion on Valgrind memory leaks - Dakar or real? within the C Programming forums, part of the General Programming Boards category; Hi, I'm trying to figure out a possible memory leak in my C program. I get the following message from ...

  1. #1
    Registered User
    Join Date
    Oct 2009
    Posts
    3

    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...
    Last edited by DaleCooper; 10-12-2009 at 03:30 AM. Reason: Ridiculous title

  2. #2
    Registered User C_ntua's Avatar
    Join Date
    Jun 2008
    Posts
    1,853
    Haven't used valgrind but you can post some code maybe?

  3. #3

  4. #4
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    Quote Originally Posted by DaleCooper View Post
    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.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  5. #5
    Registered User
    Join Date
    Oct 2009
    Posts
    3
    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!

  6. #6
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    Quote Originally Posted by DaleCooper View Post
    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.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  7. #7
    Registered User
    Join Date
    Oct 2009
    Posts
    3
    I see, none of my functions was in the "still reachable" report, so I guess that means it's all right! I'll remember that. Thanks again!

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. tools for finding memory leaks
    By stanlvw in forum C++ Programming
    Replies: 4
    Last Post: 04-03-2009, 12:41 PM
  2. Memory leaks!!!
    By kaushik1986 in forum C++ Programming
    Replies: 2
    Last Post: 10-08-2007, 06:41 AM
  3. pointers
    By InvariantLoop in forum C Programming
    Replies: 13
    Last Post: 02-04-2005, 09:32 AM
  4. Manipulating the Windows Clipboard
    By Johno in forum Windows Programming
    Replies: 2
    Last Post: 10-01-2002, 10:37 AM
  5. Programming Puns
    By kermi3 in forum A Brief History of Cprogramming.com
    Replies: 44
    Last Post: 03-23-2002, 04:38 PM

Tags for this Thread


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21