Valgrind

From Wikipedia, the free encyclopedia

For other uses, see Valgrind (disambiguation).

Valgrind

Developer:	The valgrind Developers
Latest release:	3.2.1 / September 15, 2006
OS:	x86/Linux, AMD64/Linux, PPC32/Linux and PPC64/Linux
Use:	Profiler
License:	GPL
Website:	valgrind.org

Valgrind is a free programming tool for memory debugging, memory leak detection, and profiling.

Valgrind was originally designed to be a free version of Purify for Linux on x86, but has since evolved to become a generic framework for creating dynamic analysis tools such as checkers and profilers. It has an excellent reputation and is widely used by Linux programmers. ^[1]

The original author was Julian Seward. Several others have also made significant contributions; they include Cerion Armour-Brown, Jeremy Fitzhardinge, Tom Hughes, Nicholas Nethercote, Paul Mackerras, Dirk Mueller and Robert Walsh.

1 Overview
2 Tools
3 Platforms Supported
4 Notes
5 External links

[edit] Overview

Valgrind is in essence a virtual machine using just-in-time (JIT) (aka Binary Translation) compilation techniques. Nothing from the debugged program ever gets run directly on the host processor; instead, Valgrind first translates the program into a temporary, simpler form called ucode. After the conversion, a tool (see below) is free to do whatever transformations it would like on the ucode, before Valgrind translates the ucode back into x86 code and lets the host processor run it. A considerable amount of performance is lost in these transformations (and usually, the code the tool inserts); usually, code run with Valgrind and the "none" tool (which does nothing to the ucode) runs 4-5 times slower than normal. However, the ucode form is a lot more suitable for instrumentation, which makes it easier to write tools, and for most projects, a slowdown of this order is not a big problem during debugging.

[edit] Tools

There are multiple tools included with Valgrind (and several external ones). The default (and most used) tool is Memcheck. Memcheck inserts extra instrumentation code around almost all instructions, which keeps track of the validity (all unallocated memory starts as invalid or "undefined", until it is initialized into a deterministic state, possibly from other memory) and addressability (whether the memory address in question points to an allocated, non-freed memory block), stored in the so-called V bits and A bits, respectively. As data is moved around or manipulated, the instrumentation code keeps track of the A and V bits so they are always correct on a single-bit level. (This is in contrast to Purify, which can only detect "uninitialized memory copy", which is in itself a valid operation. For instance, the X Window System client libraries frequently copy partly uninitialized structures around, which triggers large amounts of spurious alerts with Purify, forcing programmers to turn off the warnings for uninitialized memory copying.)

In addition, Memcheck replaces the standard C memory allocator with its own implementation, which also includes memory guards around all allocated blocks (with the A bits set to "invalid"). This enables Memcheck to detect off-by-one bugs where a program reads or writes outside an allocated block by a small amount. (Other approaches to this problem include implemented bounded pointers in the compiler, which give lower chances of undetected errors, especially on memory that is allocated on the stack and not the heap, but requires recompiling all instrumented binary code.) All in all, this enables Memcheck to detect and warn about the following problems:

Use of uninitialized memory
Reading/writing memory after it has been free'd
Reading/writing off the end of malloc'd blocks
Memory leaks
and more.

The price of this is lost performance; programs running under Memcheck usually run from five to twenty times as slow as running outside Valgrind, and use a lot more memory (there is a considerable memory penalty per-allocation). Thus, few developers would run their code under Memcheck (or any other Valgrind tool) all the time; the most common situations would be either to trace down some specific bug, or to verify there are no latent bugs (of the kind Memcheck can detect) in the code.

In addition to Memcheck, Valgrind has several other tools, such as

Addrcheck, a lightweight cousin of Memcheck, running much faster and requiring less memory, but catching fewer types of bugs. This tool has been removed as of version 3.2.0.
Massif, a heap profiler.
Helgrind, a tool capable of detecting race conditions in multithreaded code.
Cachegrind, a cache profiler.

There are also several externally developed tools available.

[edit] Platforms Supported

As of version 3.0.0, Valgrind supports Linux on x86, x86-64 and PowerPC. There are, however, unofficial ports to other UNIX-like platforms (like FreeBSD [1] and NetBSD [2]). There is no port for Microsoft Windows at the moment (nor are there any official short-term plans for one), but there is an experimental version capable of interfacing with WINE for debugging Windows software running on Linux. Increasing platform support is a long-term goal, but requires much work due to the nature of the project.