Valgrind heap summary understanding

Question

I am running a code and I encounter the error as

* glibc detected * /home/build/bin/../bin/OPENSUSE_12.2_X86_64/reader: corrupted double-linked list: 0x0000000003df6dc0 *

I tried to re-run it by valgrind to know whether if any memory leak is the problem. I run it as

valgrind --leak-check=full -v ./myprog

since the program does not complete and stops the valgrind summary is as below:

 > ==5335== Process terminating with default action of signal 2 (SIGINT) > ==5335== at 0x54E4007: kill (in /lib64/libc-2.15.so) > ==5335== by 0x429473: ??? (in /bin/bash) > ==5335== by 0x42A313: wait_for (in /bin/bash) > ==5335== by 0x462BFE: execute_command_internal (in /bin/bash) > ==5335== by 0x463360: execute_command (in /bin/bash) > ==5335== by 0x41B7F0: reader_loop (in /bin/bash) > ==5335== by 0x41B4C9: main (in /bin/bash) > ==5335== > ==5335== HEAP SUMMARY: > ==5335== in use at exit: 37,513 bytes in 1,074 blocks > ==5335== total heap usage: 1,922 allocs, 848 frees, 72,605 bytes allocated > ==5335== > ==5335== Searching for pointers to 1,074 not-freed blocks > ==5335== Checked 220,224 bytes > ==5335== > ==5335== LEAK SUMMARY: > ==5335== definitely lost: 0 bytes in 0 blocks > ==5335== indirectly lost: 0 bytes in 0 blocks > ==5335== possibly lost: 0 bytes in 0 blocks > ==5335== still reachable: 37,513 bytes in 1,074 blocks > ==5335== suppressed: 0 bytes in 0 blocks > ==5335== Reachable blocks (those to which a pointer was found) are not shown. > ==5335== To see them, rerun with: --leak-check=full --show-reachable=yes > ==5335== > ==5335== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) > --5335-- > --5335-- used_suppression: 2 dl-hack3-cond-1 > ==5335== > ==5335== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

in the total heap usage: 1,922 allocs, 848 frees and I wonder if here might be any problem? but in error summary there is no error. I wonder if I should be concerned about any problem in the code or memory leak?

Answer 1

This summary basically means that you didn't discard any pointers (set them to NULL ) without first freeing associated allocated memory. When the program exits, any allocated memory (whether leaked or not) will be freed regardless. However, you are correct - you are not leaking any memory, so if your program runs for an extended period of time, you won't run out of heap space.

Ideally though, you should still try to clean up after yourself - look for malloc calls, without any corresponding free calls.