Valgrind 2.2.0: Memory Debugging and Profiling

For tracking down memory leaks and other performance issues, the ease and flexibility of Valgrind may make up for slow runtimes.

Memory and performance problems plague most of us, but tools are
available that can help. One of the best, most powerful and easiest
to use is Valgrind. One thing stands out when you use Valgrind--you do
not need to recompile, relink or modify your source code. Valgrind is an
open-source project available under the GPL 2 license.

Valgrind works on all x86 systems and is being adapted to run
on the PowerPC architecture. It works with all major Linux
distributions. Valgrind's benefits include:

Tracks are addressable at the byte-level and
initialization of values at the bit-level. So Valgrind detects the use of
single uninitialized bits and does not report spurious errors on
bitfield operations.

It runs programs about 10--30x slower than
normal.

Addrcheck is a lightweight version of Memcheck. It does not check for
uninitialized data. The tradeoff is that Addrcheck detects fewer errors
than Memcheck but runs about twice as fast (about 5--20x slower
than normal). Also, a lot less memory is used. This means programs can
be run for longer and cover more test scenarios. And Valgrind still
finds a lot of important bugs in this mode. The authors suggest that you
use Addrcheck most of the time for finding memory bugs, and occasionally
use Memcheck for more thorough checking.

Cachegrind is a cache profiler. It simulates the I1, D1 and L2 caches
in your CPU and pinpoints the sources of cache misses in your code. It
identifies the number of cache misses, memory references and instructions
executed for each line of source code, with per-function, per-module
and whole-program summaries. It is useful with programs written in any
language. Cachegrind runs programs about 20--100x slower than normal.

Massif is a heap profiler. It performs detailed heap profiling by taking
regular snapshots of a program's heap. It produces a graph showing heap
usage over time, including information about which parts of the program
are responsible for the most memory allocations. The graph is supplemented
by a text or HTML file that includes more information for determining
where the most memory is being allocated. Massif runs programs about 20x
slower than normal. Massif was introduced in version 2.1.1 of Valgrind.

Helgrind is a thread debugger that finds data races in multithreaded
programs. It looks for memory locations accessed by
more than one (POSIX p-)thread but for which no consistently used
(pthread_mutex_)lock can be found. Such locations are indicative of
missing synchronization between threads and could cause hard-to-find
timing-dependent problems. It is useful for any program that uses
pthreads. It is experimental, so the authors really welcome your
feedback here.

Additional Tools

To make Valgrind even easier to use or to extend its functionality,
a number of other tools are available, including Kcachegrind, an
extension to Cachegrind that provides more data about call graphs.
Its visualization tool also gives a much better overview of the data it collects.
There also are patches for vgprof, a Valgrind tool, that profiles in the
same manner as gprof but doesn't require recompilation. It works with threaded programs
and can profile shared libraries. Several experimental tools also are
available, including a memory access tracer, a pointer misuse-checker and a signal-handler checker.
Another patch for Valgrind adds watch points on memory locations.

Graphical Front Ends

Several graphical front ends have been built for Valgrind. These are
the ones we know about: Alleyoop, which is built with Gtk+ and GNOME
libraries; Valgui; and Gnogrind. Also, KDevelop v3.0.0 allows you
to use Valgrind as a plugin.

Using Valgrind

Using Valgrind is simple: prefix your normal command line with the
Valgrind command and parameters. For example, to run myProg with myArg1
and myArg2 under Valgrind, I would enter:

where valgrind-tool is one of the tools discussed above. No recompile, relink
or source code change is needed. However, if you are
checking for memory problems, you receive more specific information if
you have compiled your program with debugging turned on (the -g option),
disabled inlining and disabled most optimization.

In the case where your program or the libraries it is using
have problems, Valgrind can suppress messages caused by known
errors. Suppression of error messages is tool-specific.

Valgrind has a number of options. It reads its options from four places,
in order, so you can set up your own debugging environment: the file
~/.valgrindrc, the environment variable $VALGRIND_OPTS, the file
./.valgrindrc and the command line.

It Isn't Perfect

Valgrind isn't perfect, and it has a number of limitations beyond
slowing down a program. The authors have listed the following
constraints. See if they apply to you. It runs with x86-GNU/Linux ELF
dynamically linked binaries, on a kernel 2.4.X or 2.6.X system, with
the following caveats:

3DNow instructions are not
implemented.

Pthreads have significant limitations.

The floating point registers should not be used for
memory-to-memory copies.

If your program does its own memory management instead
of using the standard management, then Valgrind's memory checking is
limited.

x86 instructions and system calls translation have been
implemented in an on-demand basis. Thus, a program may fail during
execution with an unimplemented instruction or system
call.

x86 floating point works correctly but may run quite
slowly.

Running under Valgrind increases you memory
footprint.

Valgrind can handle dynamically generated code just
fine. However, if you regenerate code over the top of old code (that is, at
the same memory addresses) Valgrind does not realize the code has
changed and runs its old translations, which are be out-of-date.
You need to use the VALGRIND_DISCARD_TRANSLATIONS client request in that
case. For the same reason GCC's trampolines for nested functions
currently are unsupported; see bug 69511.

Emacs is known not to work with Valgrind because Emacs
has its own memory-management scheme. Emacs works fine if you build it
using the standard malloc/free routines.

On Red Hat 7.3, there have been reports of link errors
(at program start time) for threaded programs using
__pthread_clock_gettime and __pthread_clock_settime.

Example

The simple program below shows what Memcheck and Addrcheck can
do. It is interesting to compare the output from each tool.

Reg. Charney has been a techie, an entrepreneur and businessman.
He also has been a long-time Linux enthusiast and now is developing a
series of business applications for Linux. His favorite language is
Python.

Comment viewing options

Valgrind is cool. It is very easy to use and very powerful. The programs run quite slow and sometimes I do simplify the computing intensive algorithms to be able to run my real-time applications under valgrind, but again: Valgrind is cool.