Valgrind

From Wikipedia, the free encyclopedia

Jump to: navigation, search
Valgrind
Developed by The Valgrind Developers
Latest release 3.4.1 / 2009-02-28; 37 days ago
Operating system Unix-like
Type Profiler, Memory debugger
License GNU General Public License
Website http://valgrind.org/

Valgrind is a programming tool for memory debugging, memory leak detection, and profiling. The name Valgrind comes from the name of the main entrance to Valhalla in Norse mythology.[1]

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.[2]

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

Released under the terms of the GNU General Public License, Valgrind is free software.

Contents

[edit] 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 4-5 times slower than normal. However, the IR form is much more suitable for instrumentation than the original, 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.

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. (Other approaches to this problem include implemented bounded pointers in the compiler that 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.) The problems Memcheck can detect and warn about include the following:

  • Use of uninitialized memory
  • Reading/writing memory after it has been free'd
  • 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 as slow as running outside Valgrind, and use a lot more memory (there is a considerable memory penalty per-allocation). Thus, few developers 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:

  • 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 and its GUI KCacheGrind

There are also several externally developed tools available.

[edit] Platforms supported

As of version 3.3.0, Valgrind supports Linux on x86, x86-64 and PowerPC. There are, however, unofficial ports to other UNIX-like platforms (like FreeBSD[6], NetBSD[7], and Mac OS X[8]). 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.

[edit] Limitations

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

  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 inability to detect this kind of error is especially noteworthy since certain types of stack errors make software vulnerable to the classic stack smashing exploit.

[edit] Notes

[edit] References

[edit] External links

Personal tools