Decoding output from Valgrind

Question

I'm trying to understand the output from Valgrind having executed it as follows:

valgrind --leak-check=yes "someprogram"

The output is here:

==30347==
==30347== HEAP SUMMARY:
==30347==     in use at exit: 126,188 bytes in 2,777 blocks
==30347==   total heap usage: 4,562 allocs, 1,785 frees, 974,922 bytes
        allocated
==30347==
==30347== LEAK SUMMARY:
==30347==    definitely lost: 0 bytes in 0 blocks
==30347==    indirectly lost: 0 bytes in 0 blocks
==30347==      possibly lost: 0 bytes in 0 blocks
==30347==    still reachable: 126,188 bytes in 2,777 blocks
==30347==         suppressed: 0 bytes in 0 blocks
==30347== Reachable blocks (those to which a pointer was found) are
          not shown.
==30347== To see them, rerun with: --leak-check=full --show-reachable=yes
==30347==
==30347== For counts of detected and suppressed errors, rerun with: -v
==30347== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

According to the output, there are no lost bytes, but there seems to be still reachable blocks. So do I have a memory leak?

Answer 1

No.

You are most concerned with unreachable blocks. What you are seeing here is that there are active variables that are still "pointing" at reachable blocks of memory. They are still in scope.

An unreachable block would be, for instance, memory that you have allocated dynamically, used for a period of time and then all of the references to it have gone out of scope even though the program is still executing. Since you no longer have any handles pointing to them they are now unrecoverable, creating a memory leak.

Here is a quote from the Valgrind docs:

"still reachable" means your program is probably ok -- it didn't free some memory it could have. This is quite common and often reasonable. Don't use --show-reachable=yes if you don't want to see these reports.