Valgrind (pronounced /ˈvælɡrɪnd/) is a programming tool for memory debugging, memory leak detection, and profiling. The name valgrind comes from 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] Since version 3.5, Valgrind also works on Mac OS X.
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, Bart Van Assche, Josef Weidendorfer and Robert Walsh.[5]
Released under the terms of the GNU General Public License, Valgrind is free software.
Contents |
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.
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 and DRD, tools capable of detecting race conditions in multithreaded code.
- Cachegrind, a cache profiler and its GUI KCacheGrind
- exp-ptrcheck an experimental tool to find similar bugs as memcheck can do, but with a different approach that is capable of finding a few additional ones.[citation needed]
There are also several externally developed tools available.[citation needed]
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.[6] There are unofficial ports to other UNIX-like platforms (like FreeBSD[7], and NetBSD[8]).
Limitations of Memcheck
In addition to the performance penalty an important limitation of Memcheck 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.
However, the Valgrind experimental tool Ptrcheck can detect errors like this.
Notes
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. http://portal.acm.org/citation.cfm?id=1250734.1250746&coll=GUIDE&dl=GUIDE&CFID=8869850&CFTOKEN=10168503.
- 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. http://portal.acm.org/citation.cfm?id=1247362&dl=GUIDE&coll=GUIDE&CFID=8869850&CFTOKEN=10168503.
- 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 0954612051. http://www.network-theory.co.uk/valgrind/manual/.
External links
This entry is from Wikipedia, the leading user-contributed encyclopedia. It may not have been reviewed by professional editors (see full disclaimer)
