Valgrind detects unfreed heap memory usage for a trivial code

Question

My valgrind is telling me that it found non-freed heap memory for the most trivial C++ code.

My code is shown as follows:

#include <iostream>
#include <string>
int main() {
std::cout << "Hello!!!!" << std::endl;
return 0;
}

And the result of valgrind is here:

==12455== HEAP SUMMARY:
==12455==     in use at exit: 72,704 bytes in 1 blocks
==12455==   total heap usage: 2 allocs, 1 frees, 73,728 bytes allocated
==12455== 
==12455== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==12455==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12455==    by 0x4EC3EFF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==12455==    by 0x40106C9: call_init.part.0 (dl-init.c:72)
==12455==    by 0x40107DA: call_init (dl-init.c:30)
==12455==    by 0x40107DA: _dl_init (dl-init.c:120)
==12455==    by 0x4000C69: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==12455== 
==12455== LEAK SUMMARY:
==12455==    definitely lost: 0 bytes in 0 blocks
==12455==    indirectly lost: 0 bytes in 0 blocks
==12455==      possibly lost: 0 bytes in 0 blocks
==12455==    still reachable: 72,704 bytes in 1 blocks
==12455==         suppressed: 0 bytes in 0 blocks
==12455== 
==12455== For counts of detected and suppressed errors, rerun with: -v
==12455== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Is this a bug of valgrind?

There's a difference between being "*technically correct*" (valgrind) and being "usefully correct". Your standard library probably (intentionally) leaks some memory related to `cout`, but that's not necessarily a problem. Once your program dies, the kernel will reclaim all memory it ever allocated. So the leak doesn't *matter*. — Jesper Juhl, May 10 '19 at 18:10
From my experience, this is not a bug in valgrind, this is how valgrind output looks like. — YatShan, May 10 '19 at 18:10
[Still Reachable Leak detected by Valgrind](https://stackoverflow.com/questions/3840582): `[...]In general, there is no need to worry about "still reachable" blocks. They don't pose the sort of problem that true memory leaks can cause. For instance, there is normally no potential for heap exhaustion from "still reachable" blocks.[...]` — t.niese, May 10 '19 at 18:12

score 0 · Accepted Answer · edited May 10 '19 at 18:16

This is due to the way the C++ standard library works. The containers allocate chunks of memory (called pools) and manage them internally. They use basically a memory manager of their own, rather than relying on system's memory manager. Therefore, when an object is destroyed, it's memory is freed by the internal allocator for reuse, but not given back to the operating system.

This is also described in valgrind's FAQ here.

To generalize a bit more, valgrind is a very useful tool, but you should not aim for 0 leaks, but rather to understand its reports and find leaks that indicate a problem in the code.

score 0 · Answer 2 · answered May 10 '19 at 18:28

0

I use valgrind 3.14.0 under Ubuntu 19.04 and i dont get any detections. I ran with --leak-check=fulland without. Maybe its just some versions of valgrind.

answered May 10 '19 at 18:28

Yastanub

1,227
8
19

I am using valgrind-3.11.0 under Ubuntu 16.04.6. – JIN TLG May 10 '19 at 18:32

Valgrind detects unfreed heap memory usage for a trivial code

2 Answers2