The Valgrind Quick Start Guide
It’s worth fixing errors in the order they are reported, as later errors can be caused by earlier errors. Failing to do this
is a common cause of difficulty with Memcheck.
Memory leak messages look like this:
==19182== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==19182==
at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130)
==19182==
by 0x8048385: f (a.c:5)
==19182==
by 0x80483AB: main (a.c:11)
The stack trace tells you where the leaked memory was allocated. Memcheck cannot tell you why the memory leaked,
unfortunately. (Ignore the "vg_replace_malloc.c", that’s an implementation detail.)
There are several kinds of leaks; the two most important categories are:
• "definitely lost": your program is leaking memory -- fix it!
• "probably lost": your program is leaking memory, unless you’re doing funny things with pointers (such as moving
them to point to the middle of a heap block).
Memcheck also reports uses of uninitialised values, most commonly with the message "Conditional jump or move
depends on uninitialised value(s)".
It can be difficult to determine the root cause of these errors. Try using the
--track-origins=yes
to get extra information. This makes Memcheck run slower, but the extra information
you get often saves a lot of time figuring out where the uninitialised values are coming from.
If you don’t understand an error message, please consult
Explanation of error messages from Memcheck
in the
Valgrind User Manual
which has examples of all the error messages Memcheck produces.
5. Caveats
Memcheck is not perfect; it occasionally produces false positives, and there are mechanisms for suppressing these
(see
Suppressing errors
in the
Valgrind User Manual
). However, it is typically right 99% of the time, so you should be
wary of ignoring its error messages. After all, you wouldn’t ignore warning messages produced by a compiler, right?
The suppression mechanism is also useful if Memcheck is reporting errors in library code that you cannot change.
The default suppression set hides a lot of these, but you may come across more.
Memcheck cannot detect every memory error your program has. For example, it can’t detect out-of-range reads or
writes to arrays that are allocated statically or on the stack.
But it should detect many errors that could crash your
program (eg. cause a segmentation fault).
Try to make your program so clean that Memcheck reports no errors. Once you achieve this state, it is much easier to
see when changes to the program cause Memcheck to report new errors. Experience from several years of Memcheck
use shows that it is possible to make even huge programs run Memcheck-clean.
For example, large parts of KDE,
OpenOffice.org and Firefox are Memcheck-clean, or very close to it.
6. More information
Please consult the
Valgrind FAQ
and the
Valgrind User Manual
, which have much more information. Note that the
other tools in the Valgrind distribution can be invoked with the
--tool
option.
3
