PRE-2016 Valgrind: Memory still reachable with trivial program using

It’s Valgrind’s fault. First, -fsanitize=leak does not show anything. Second, Valgrind itself states that:

First of all: relax, it’s probably not a bug, but a feature. Many
implementations of the C++ standard libraries use their own memory
pool allocators. Memory for quite a number of destructed objects is
not immediately freed and given back to the OS, but kept in the
pool(s) for later re-use. The fact that the pools are not freed at the
exit of the program cause Valgrind to report this memory as still
reachable. The behaviour not to free pools at the exit could be called
a bug of the library though.

Using GCC, you can force the STL to use malloc and to free memory as
soon as possible by globally disabling memory caching. Beware! Doing
so will probably slow down your program, sometimes drastically.

With GCC 2.91, 2.95, 3.0 and 3.1, compile all source using the STL
with -D__USE_MALLOC. Beware! This was removed from GCC starting with
version 3.3.

With GCC 3.2.2 and later, you should export the environment variable
GLIBCPP_FORCE_NEW before running your program.

With GCC 3.4 and later, that variable has changed name to
GLIBCXX_FORCE_NEW.

[…]

I guess those alleged memory pools are freed after program’s termination, in the so-called start-up code that calls main, among the other settings. Internal functions defined outside user’s code should be treated as if they didn’t exist, that’s why Valgrind can’t (and shouldn’t) see further frees.

Leave a Comment