Valgrind

For other uses, see Valgrind (disambiguation).

Valgrind

Developer(s)	The Valgrind Developers
Stable release	3.8.1 / September 18, 2012 (2012-09-18)
Operating system	GNU/Linux Mac OS X Android
Type	Profiler, Memory debugger
License	GNU General Public License
Website	www.valgrind.org

Valgrind /ˈvælɡrɪnd/ is a GPL licensed programming tool for memory debugging, memory leak detection, and profiling. It is named after the main entrance to Valhalla in Norse mythology.

Valgrind was originally designed to be a free memory debugging tool for Linux on x86, but has since evolved to become a generic framework for creating dynamic analysis tools such as checkers and profilers. It is used by a number of Linux-based projects. Since version 3.5, Valgrind also works on Mac OS X.

The original author of Valgrind is Julian Seward, who in 2006 won a Google-O'Reilly Open Source Award for his work on Valgrind. Several others have also made significant contributions, including Cerion Armour-Brown, Jeremy Fitzhardinge, Tom Hughes, Nicholas Nethercote, Paul Mackerras, Dirk Mueller, Bart Van Assche, Josef Weidendorfer and Robert Walsh.

Overview

Valgrind is in essence a virtual machine using just-in-time (JIT) compilation techniques, including dynamic recompilation. Nothing from the original program ever gets run directly on the host processor. Instead, Valgrind first translates the program into a temporary, simpler form called Intermediate Representation (IR), which is a processor-neutral, SSA-based form. After the conversion, a tool (see below) is free to do whatever transformations it would like on the IR, before Valgrind translates the IR back into machine code and lets the host processor run it. Even though it could use dynamic translation (that is, the host and target processors are from different architectures), it doesn't. Valgrind recompiles binary code to run on host and target (or simulated) CPUs of the same architecture.

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 IR) runs at 1/4th to 1/5th of the speed of the normal program.^{[citation needed]}

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.

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 feature enables Memcheck to detect off-by-one errors where a program reads or writes outside an allocated block by a small amount. The problems Memcheck can detect and warn about include the following:

• Use of uninitialized memory
• Reading/writing memory after it has been freed
• Reading/writing off the end of malloc'd blocks
• Memory leaks

The price of this is lost performance. Programs running under Memcheck usually run from five to twenty times slower^{[citation needed]} than running outside Valgrind and use more memory (there is a memory penalty per-allocation). Thus, few developers run their code under Memcheck (or any other Valgrind tool) all the time. They most commonly use such tools 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:

• Addrcheck, a lightweight cousin of Memcheck, running much faster and requiring less memory, but catching fewer types of bugs. Addrcheck has been removed as of version 3.2.0.
• Massif, a heap profiler.
• Helgrind and DRD, tools capable of detecting race conditions in multithreaded code.
• Cachegrind, a cache profiler and its GUI KCacheGrind.
• Callgrind, an extension to Cachegrind created by Josef Weidendorfer which produces more information about callgraphs. It was folded into the mainline version of Valgrind in version 3.2.0. KCacheGrind is capable of visualizing output from Callgrind as well as Cachegrind.
• exp-sgcheck (named exp-ptrcheck prior to version 3.7), an experimental tool to find stack and global array overrun errors which Memcheck cannot find.
• exp-dhat, dynamic heap analysis tool which analyzes how much memory is allocated and for how long as well as patterns of memory usage.
• exp-bbv, a performance simulator that extrapolates performance from a small sample set.

There are also several externally developed tools available. One of such tools is ThreadSanitizer, a detector of race conditions.

Platforms supported

As of version 3.4.0, Valgrind supports Linux on x86, x86-64 and PowerPC. Support for Mac OS X was added in version 3.5.0. Support for Linux on ARMv7 (used for example in certain smartphones) was added in version 3.6.0. There are unofficial ports to other UNIX-like platforms (like FreeBSD, and NetBSD). From version 3.7.0 the ARM/Android platform support was added.

Limitations of Memcheck

In addition to the performance penalty an important limitation of Memcheck is its inability to detect all cases of bounds errors in the use of static or stack allocated data. The following code will pass the Memcheck tool in Valgrind without incident, despite containing the errors described in the comments:

  int Static[5];
 
  int func(void)
  {
    int Stack[5];
 
    Static[5] = 0;  /* Error - Static[0] to Static[4] exist, Static[5] is out of bounds */
    Stack [5] = 0;  /* Error - Stack[0] to  Stack[4] exist,  Stack[5] is out of bounds */
 
    return 0;
  }

The experimental valgrind tool exp-sgcheck has been written to address this limitation in Memcheck. It will detect array overrun errors provided the first access to an array is within the array bounds. exp-sgcheck will not detect the array overrun in the code above, since the first access to an array is out of bounds, but it will detect the array overrun error in the following code.

  void func(void)
  {
    int i, Stack[5];
 
    for (i = 0; i <= 5; i++)
        Stack [i] = 0;        /* Within bounds for i=0..4, out of bounds error when i=5 */
  }

The inability to detect all errors in access of stack allocated data is especially noteworthy since certain types of stack errors make software vulnerable to the classic stack smashing exploit.

See also

• Dynamic program analysis
• Pin
• DynamoRIO

References

• Nicholas Nethercote and Julian Seward. "Valgrind: A Framework for Heavyweight Dynamic Binary Instrumentation". Proceedings of ACM SIGPLAN 2007 Conference on Programming Language Design and Implementation (PLDI 2007). ACM. 
• Julian Seward and Nicholas Nethercote. "Using Valgrind to detect undefined value errors with bit-precision". Proceedings of the USENIX Annual Technical Conference 2005. USENIX Association. 
• J. Seward, N. Nethercote, J. Weidendorfer and the Valgrind Development Team (March 2008). Valgrind 3.3 — Advanced Debugging and Profiling for GNU/Linux applications. Network Theory Ltd. pp. 164 pages. ISBN 0-9546120-5-1. 

External links

• Official website
• Overview of the Valgrind system
• Complete manual of Valgrind
• Projects using Valgrind