understanding valgrind output [duplicate]

Question

I made a post earlier asking about checking for memory leaks, etc. I did say I wasn’t to familiar with the terminal in Linux, but someone said to me it was easy with Valgrind.

I have managed to get it running, etc., but I am not to sure what the output means. Glancing over, all looks good to me, but would like to run it past you experience folk for confirmation if possible. The output is as follows:

^C==2420==
==2420== HEAP SUMMARY:
==2420==     in use at exit: 2,240 bytes in 81 blocks
==2420==   total heap usage: 82 allocs, 1 frees, 2,592 bytes allocated
==2420==
==2420== LEAK SUMMARY:
==2420==    definitely lost: 0 bytes in 0 blocks
==2420==    indirectly lost: 0 bytes in 0 blocks
==2420==      possibly lost: 0 bytes in 0 blocks
==2420==    still reachable: 2,240 bytes in 81 blocks
==2420==         suppressed: 0 bytes in 0 blocks
==2420== Reachable blocks (those to which a pointer was found) are not shown.
==2420== To see them, rerun with: --leak-check=full --show-reachable=yes
==2420==
==2420== For counts of detected and suppressed errors, rerun with: -v
==2420== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 8)

Is all good here? The only thing concerning me is the still reachable part. Is that OK?

Answer 1

I suggest you stop, and read the Valgrind Quick Start, paying particular attention to section 4, "Interpreting Memcheck's output," and look over the FAQ.

---

Afterward, I think you could benefit from reading How to Ask Questions The Smart Way (aka Smart Questions) to improve your problem solving skills, and improve your asking for assistance in community sites like Stack Overflow, where better questions are rewarded with better answers.

This is not intended to be an insult or personal attack, but a suggestion on how you can ask questions better, so you can get better answers. You will also learn how to answer your own basic questions yourself more often in the process, speeding up your overall efforts. Good luck.

Answer 2

The output you pasted shows:

==2420== total heap usage: 82 allocs, 1 frees, 2,592 bytes allocated

...

==2420== still reachable: 2,240 bytes in 81 blocks

82 allocations and only one free, so in the end there are 81 blocks still 'reachable' on the heap. As the Valgrind FAQ states, this may indicate that the code uses some memory pool allocator and therefore does not free memory as soon as it's unused, but rather keeps it for later use, or it may actually be a memory leak (unlikely, though). Follow the steps in the link to check whether this is due to the STLs use of memory caching.