1. Background | |
1.1. How do you pronounce "Valgrind"? 1.2. Where does the name "Valgrind" come from? | |
1.1. | How do you pronounce "Valgrind"? |
The "Val" as in the word "value". The "grind" is pronounced with a short 'i' -- ie. "grinned" (rhymes with "tinned") rather than "grined" (rhymes with "find"). Don't feel bad: almost everyone gets it wrong at first. |
|
1.2. | Where does the name "Valgrind" come from? |
From Nordic mythology. Originally (before release) the project was named Heimdall, after the watchman of the Nordic gods. He could "see a hundred miles by day or night, hear the grass growing, see the wool growing on a sheep's back", etc. This would have been a great name, but it was already taken by a security package "Heimdal". Keeping with the Nordic theme, Valgrind was chosen. Valgrind is the name of the main entrance to Valhalla (the Hall of the Chosen Slain in Asgard). Over this entrance there resides a wolf and over it there is the head of a boar and on it perches a huge eagle, whose eyes can see to the far regions of the nine worlds. Only those judged worthy by the guardians are allowed to pass through Valgrind. All others are refused entrance. It's not short for "value grinder", although that's not a bad guess. |
2. Compiling, installing and configuring | |
2.1. When building Valgrind, 'make' dies partway with
an assertion failure, something like this: 2.2. When building Valgrind, 'make' fails with this: | |
2.1. |
When building Valgrind, 'make' dies partway with
an assertion failure, something like this:% make: expand.c:489: allocated_variable_append: Assertion 'current_variable_set_list->next != 0' failed. |
It's probably a bug in 'make'. Some, but not all, instances of version 3.79.1 have this bug, see this. Try upgrading to a more recent version of 'make'. Alternatively, we have heard that unsetting the CFLAGS environment variable avoids the problem. |
|
2.2. |
When building Valgrind, 'make' fails with this:/usr/bin/ld: cannot find -lc collect2: ld returned 1 exit status |
You need to install the glibc-static-devel package. |
3. Valgrind aborts unexpectedly | |
3.1. Programs run OK on Valgrind, but at exit produce a bunch of
errors involving __libc_freeres and then die
with a segmentation fault. 3.2. My (buggy) program dies like this: 3.3. My program dies, printing a message like this along the way: 3.4. I tried running a Java program (or another program that uses a just-in-time compiler) under Valgrind but something went wrong. Does Valgrind handle such programs? | |
3.1. | Programs run OK on Valgrind, but at exit produce a bunch of
errors involving __libc_freeres and then die
with a segmentation fault. |
When the program exits, Valgrind runs the procedure
The problem is that running Workaround for 1.1.X and later versions of Valgrind: use the
|
|
3.2. |
My (buggy) program dies like this:valgrind: m_mallocfree.c:248 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed.or like this: valgrind: m_mallocfree.c:442 (mk_inuse_bszB): Assertion 'bszB != 0' failed.or otherwise aborts or crashes in m_mallocfree.c. |
If Memcheck (the memory checker) shows any invalid reads, invalid writes or invalid frees in your program, the above may happen. Reason is that your program may trash Valgrind's low-level memory manager, which then dies with the above assertion, or something similar. The cure is to fix your program so that it doesn't do any illegal memory accesses. The above failure will hopefully go away after that. |
|
3.3. |
My program dies, printing a message like this along the
way:vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x2E 0x5 |
One possibility is that your program has a bug and erroneously jumps to a non-code address, in which case you'll get a SIGILL signal. Memcheck may issue a warning just before this happens, but it might not if the jump happens to land in addressable memory. Another possibility is that Valgrind does not handle the instruction. If you are using an older Valgrind, a newer version might handle the instruction. However, all instruction sets have some obscure, rarely used instructions. Also, on amd64 there are an almost limitless number of combinations of redundant instruction prefixes, many of them undocumented but accepted by CPUs. So Valgrind will still have decoding failures from time to time. If this happens, please file a bug report. |
|
3.4. | I tried running a Java program (or another program that uses a just-in-time compiler) under Valgrind but something went wrong. Does Valgrind handle such programs? |
Valgrind can handle dynamically generated code, so long as
none of the generated code is later overwritten by other generated
code. If this happens, though, things will go wrong as Valgrind
will continue running its translations of the old code (this is true
on x86 and amd64, on PowerPC there are explicit cache flush
instructions which Valgrind detects and honours).
You should try running with
Alternatively, if you have the source code to the JIT compiler
you can insert calls to the
Apart from this, in theory Valgrind can run any Java program just fine, even those that use JNI and are partially implemented in other languages like C and C++. In practice, Java implementations tend to do nasty things that most programs do not, and Valgrind sometimes falls over these corner cases. If your Java programs do not run under Valgrind, even with
|
4. Valgrind behaves unexpectedly | |
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. 4.2. The stack traces given by Memcheck (or another tool) aren't helpful. How can I improve them? 4.3. The stack traces given by Memcheck (or another tool) seem to have the wrong function name in them. What's happening? 4.4. My program crashes normally, but doesn't under Valgrind, or vice versa. What's happening? 4.5. Memcheck doesn't report any errors and I know my program has errors. 4.6. Why doesn't Memcheck find the array overruns in this program? 4.7. Why does Memcheck report many "Mismatched free() / delete / delete []" errors when my code is correct? | |
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.
There are other ways to disable memory pooling: using the
|
|
4.2. | The stack traces given by Memcheck (or another tool) aren't helpful. How can I improve them? |
If they're not long enough, use If they're not detailed enough, make sure you are compiling
with 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 Also, Some example sub-traces:
|
|
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 printing |
|
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
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 valgrind-listener 12345 Obviously you have to start the listener process first. See the manual for more details. Second, if your program is statically linked, most Valgrind
tools will only work well if they are able to replace certain
functions, such as All heap blocks were freed -- no leaks are possible
when you know your program calls There will also be no replacement if you use an alternative
|
|
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. |
|
4.7. | Why does Memcheck report many "Mismatched free() / delete / delete []" errors when my code is correct? |
There are two possible causes of this. First, check if you are using an optimized build of Google tcmalloc (part of Google perftools). This library uses a single alias for free/scalar delete/array delete as an unmeasurable micro-optimization. There is simply no way for Memcheck to tell which of these was originally used. There are a few possible workarounds.
Second, if you are replacing operator new or operator delete make sure that the compiler does not perform optimizations such as inlining on calls to these functions. Such optimizations can prevent Memcheck from correctly identifying the allocator or deallocator that is being used. The following two code snippets show how you can do this with GCC and LLVM (clang). // GCC void operator delete(void*) noexcept __attribute__((__externally_visible__)); // LLVM (clang) __attribute__((__visibility__("default"))) void operator delete(void*) noexcept; If all else fails, you might have to use "--show-mismatched-frees=no" |
5. Miscellaneous | |
5.1. I tried writing a suppression but it didn't work. Can you
write my suppression for me? 5.2. With Memcheck's memory leak detector, what's the difference between "definitely lost", "indirectly lost", "possibly lost", "still reachable", and "suppressed"? 5.3. Memcheck's uninitialised value errors are hard to track down, because they are often reported some time after they are caused. Could Memcheck record a trail of operations to better link the cause to the effect? Or maybe just eagerly report any copies of uninitialised memory values? 5.4. Is it possible to attach Valgrind to a program that is already running? | |
5.1. | I tried writing a suppression but it didn't work. Can you write my suppression for me? |
Yes! Use the If you really want to write suppressions by hand, read the manual carefully. Note particularly that C++ function names must be mangled (that is, not demangled). |
|
5.2. | With Memcheck's memory leak detector, what's the difference between "definitely lost", "indirectly lost", "possibly lost", "still reachable", and "suppressed"? |
The details are in the Memcheck section of the user manual. In short:
|
|
5.3. | Memcheck's uninitialised value errors are hard to track down, because they are often reported some time after they are caused. Could Memcheck record a trail of operations to better link the cause to the effect? Or maybe just eagerly report any copies of uninitialised memory values? |
Prior to version 3.4.0, the answer was "we don't know how to do it
without huge performance penalties". As of 3.4.0, try using the
Or if you want to do it the old fashioned way, you can use the
client request
As for eager reporting of copies of uninitialised memory values, this has been suggested multiple times. Unfortunately, almost all programs legitimately copy uninitialised memory values around (because compilers pad structs to preserve alignment) and eager checking leads to hundreds of false positives. Therefore Memcheck does not support eager checking at this time. |
|
5.4. | Is it possible to attach Valgrind to a program that is already running? |
No. The environment that Valgrind provides for running programs is significantly different to that for normal programs, e.g. due to different layout of memory. Therefore Valgrind has to have full control from the very start. It is possible to achieve something like this by running your
program without any instrumentation (which involves a slow-down of about
5x, less than that of most tools), and then adding instrumentation once
you get to a point of interest. Support for this must be provided by
the tool, however, and Callgrind is the only tool that currently has
such support. See the instructions on the
|
6. How To Get Further Assistance | |
6.1. Where can I get more help? | |
6.1. | Where can I get more help? |
Read the appropriate section(s) of the Valgrind Documentation. Search the
valgrind-users mailing list archives, using the group name
If you think an answer in this FAQ is incomplete or inaccurate, please e-mail valgrind@valgrind.org. If you have tried all of these things and are still stuck, you can try mailing the valgrind-users mailing list. Note that an email has a better change of being answered usefully if it is clearly written. Also remember that, despite the fact that most of the community are very helpful and responsive to emailed questions, you are probably requesting help from unpaid volunteers, so you have no guarantee of receiving an answer. |