4.1.My program uses the C++ STL and string classes. Valgrind reports ’still reachable’ memory leaks involving these classes at the exit of the program, but there should be none.
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 toGLIBCXX_FORCE_NEW.
There are other ways to disable memory pooling: using themalloc_alloctemplate with your objects (not portable, but should work for GCC) or even writing your own memory allocators. But all this goes beyond the scope of this FAQ. Start by reading http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#4_4_leak if you absolutely want to do that. But beware: allocators belong to the more messy parts of the STL and people went to great lengths to make the STL portable across platforms. Chances are good that your solution will work on your platform, but not on others.
If they’re not long enough, use--num-callersto make them longer.
If they’re not detailed enough, make sure you are compiling with-gto add debug information. And don’t strip symbol tables (programs should be unstripped unless you run ’strip’ on them; some libraries ship stripped). Also, for leak reports involving shared objects, if the shared object is unloaded before the program terminates, Valgrind will discard the debug information and the error message will be full of???entries. The workaround here is to avoid callingdlcloseon these shared objects.
Also,-fomit-frame-pointerand-fstack-checkcan make stack traces worse. Some example sub-traces:
• With debug information and unstripped (best):
Invalid write of size 1
at 0x80483BF: really (malloc1.c:20) by 0x8048370: main (malloc1.c:9)
• With no debug information, unstripped:
Invalid write of size 1
at 0x80483BF: really (in /auto/homes/njn25/grind/head5/a.out) by 0x8048370: main (in /auto/homes/njn25/grind/head5/a.out)
• With no debug information, stripped:
Invalid write of size 1
at 0x80483BF: (within /auto/homes/njn25/grind/head5/a.out) by 0x8048370: (within /auto/homes/njn25/grind/head5/a.out) by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so) by 0x80482CC: (within /auto/homes/njn25/grind/head5/a.out)
• With debug information and -fomit-frame-pointer:
Invalid write of size 1
at 0x80483C4: really (malloc1.c:20)
by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so) by 0x80482CC: ??? (start.S:81)
• A leak error message involving an unloaded shared object:
84 bytes in 1 blocks are possibly lost in loss record 488 of 713 at 0x1B9036DA: operator new(unsigned) (vg_replace_malloc.c:132) by 0x1DB63EEB: ???
by 0x1DB4B800: ??? by 0x1D65E007: ???
by 0x8049EE6: main (main.cpp:24)
4.3.The stack traces given by Memcheck (or another tool) seem to have the wrong function name in them. What’s happening?
Occasionally Valgrind stack traces get the wrong function names. This is caused by glibc using aliases to effectively give one function two names. Most of the time Valgrind chooses a suitable name, but very occasionally it gets it wrong. Examples we know of are printingbcmpinstead ofmemcmp,indexinstead of strchr, andrindexinstead ofstrrchr.
4.4.My program crashes normally, but doesn’t under Valgrind, or vice versa. What’s happening?
When a program runs under Valgrind, its environment is slightly different to when it runs natively. For example, the memory layout is different, and the way that threads are scheduled is different.
Most of the time this doesn’t make any difference, but it can, particularly if your program is buggy. For example, if your program crashes because it erroneously accesses memory that is unaddressable, it’s possible that this memory will not be unaddressable when run under Valgrind. Alternatively, if your program has data races, these may not manifest under Valgrind.
There isn’t anything you can do to change this, it’s just the nature of the way Valgrind works that it cannot exactly replicate a native execution environment. In the case where your program crashes due to a memory error when run natively but not when run under Valgrind, in most cases Memcheck should identify the bad memory operation.
4.5.Memcheck doesn’t report any errors and I know my program has errors. There are two possible causes of this.
First, by default, Valgrind only traces the top-level process. So if your program spawns children, they won’t be traced by Valgrind by default. Also, if your program is started by a shell script, Perl script, or something similar, Valgrind will trace the shell, or the Perl interpreter, or equivalent.
To trace child processes, use the--trace-children=yesoption.
If you are tracing large trees of processes, it can be less disruptive to have the output sent over the network. Give Valgrind the option--log-socket=127.0.0.1:12345 (if you want logging output sent to port 12345onlocalhost). You can use the valgrind-listener program to listen on that port:
valgrind-listener 12345
Second, if your program is statically linked, most Valgrind tools will only work well if they are able to replace certain functions, such asmalloc, with their own versions. By default, statically linkedmalloc functionsare not replaced. A key indicator of this is if Memcheck says:
All heap blocks were freed -- no leaks are possible
when you know your program calls malloc. The workaround is to use the option --soname-synonyms=somalloc=NONEor to avoid statically linking your program.
There will also be no replacement if you use an alternativemalloc librarysuch as tcmalloc, jemalloc, ... In such a case, the option--soname-synonyms=somalloc=zzzz(where zzzz is the soname of the alternative malloc library) will allow Valgrind to replace the functions.
4.6.Why doesn’t Memcheck find the array overruns in this program?
int static[5]; int main(void) { int stack[5]; static[5] = 0; stack [5] = 0; return 0; }
Unfortunately, Memcheck doesn’t do bounds checking on global or stack arrays. We’d like to, but it’s just not possible to do in a reasonable way that fits with how Memcheck works. Sorry.
However, the experimental tool SGcheck can detect errors like this. Run Valgrind with the --tool=exp-sgcheckoption to try it, but be aware that it is not as robust as Memcheck.