Valgrind Frequently Asked Questions
• "indirectly lost" means your program is leaking memory in a pointer-based structure. (E.g. if the root node
of a binary tree is "definitely lost", all the children will be "indirectly lost".) If you fix the "definitely lost"
leaks, the "indirectly lost" leaks should go away.
• "possibly lost" means your program is leaking memory, unless you’re doing unusual things with pointers
that could cause them to point into the middle of an allocated block; see the user manual for some possible
causes. Use
--show-possibly-lost=no
if you don’t want to see these reports.
• "still reachable" means your program is probably ok -- it didn’t free some memory it could have. This is
quite common and often reasonable. Don’t use
--show-reachable=yes
if you don’t want to see these
reports.
• "suppressed" means that a leak error has been suppressed. There are some suppressions in the default
suppression files. You can ignore suppressed errors.
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
--track-origins=yes
option.
It will run slower than usual, but will give you
extra information about the origin of uninitialised values.
Or if you want to do it the old fashioned way, you can use the client request
VALGRIND_CHECK_VALUE_IS_DEFINED
to help track these errors down -- work backwards from the point where the uninitialised error occurs, checking
suspect values until you find the cause. This requires editing, compiling and re-running your program multiple
times, which is a pain, but still easier than debugging the problem without Memcheck’s help.
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
callgrind_control
program for details.
6. How To Get Further Assistance
Read the appropriate section(s) of the Valgrind Documentation.
Search the valgrind-users mailing list archives, using the group name
gmane.comp.debugging.valgrind
.
If you think an answer in this FAQ is incomplete or inaccurate, please e-mail [email protected].
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.
8