Valgrind, an open-source memory debugger for x86-linux Valgrind, an open-source memory debugger for x86-GNU/Linux New (18 September 02): Valgrind 1.0.3 is available! Current stable version is 1.0.3 Programmers! Make your software Valgrind-clean. Test it with Valgrind and fix all problems Valgrind reports. This will give you some assurance that your code is free of a broad class of memory management errors. You may well find undiscovered bugs, and your code will probably be more stable as a result. It's good for your code, good for you and especially it's good for the people who use your code. Don't delay -- Valgrind today. Ok, that was a bad pun. But the rest is serious. Valgrind is a GPL'd tool to help you find memory-management problems in your programs. When a program is run under Valgrind's supervision, all reads and writes of memory are checked, and calls to malloc/new/free/delete are intercepted. As a result, Valgrind can detect problems such as: Use of uninitialised memory Reading/writing memory after it has been free'd Reading/writing off the end of malloc'd blocks Reading/writing inappropriate areas on the stack Memory leaks -- where pointers to malloc'd blocks are lost forever Passing of uninitialised and/or unaddressible memory to system calls Mismatched use of malloc/new/new [] vs free/delete/delete [] Some misuses of the POSIX pthreads API Valgrind tracks each byte of memory in the original program with nine status bits, one of which tracks addressibility of that byte, while the other eight track the validity of the byte. As a result, it can detect the use of single uninitialised bits, and does not report spurious errors on bitfield operations. You can use it to debug more or less any dynamically-linked ELF x86 executable, without modification, recompilation, or anything. If you want, Valgrind can start GDB and attach it to your program at the point(s) where errors are detected, so that you can poke around and figure out what was going on at the time. Valgrind works well enough to debug many large x86-linux applications. To give you some idea of the scale of programs it can run: most of KDE3, Gnome stuff, Mozilla, OpenOffice, MySQL, Opera, KOffice-1.2beta1, emacs-21.2, xemacs-21.5(--pdump), Netscape-4.78, Gcc, AbiWord, etc, etc. KDE3 was extensively valgrinded in the two months prior to the KDE 3.0 release. Valgrind is first and foremost a debugging tool for large, complex programs. It isn't a toy or a research vehicle. Valgrind contains built-in support for doing very detailed cache profiling. Since we already intercept every read and write, and have all the debugging information for your program close to hand, it's not too hard to also do a detailed simulation of your CPU's L1-D, L1-I and unified L2 caches. The supplied vg_annotate program will show your source code with these counts attached to every line. The cache arrangement of your CPU is auto-detected using the CPUID instruction. If that doesn't work or you want to override it, you can specify custom cache parameters on the command line. The manual contains full documentation of this new feature. The cache profiling aspects are the excellent hacking of Nick Nethercote. Please do try it out -- you just need to put cachegrind in front of your program invokations, rather than valgrind. We hope it will be a useful performance-analysis tool. If you plan to use the cache profiler, you might want to look at Josef Weidendorfer's amazing kcachegrind visualisation tool and call-graph extension. This makes it a lot easier to make sense of the overwhelming mass of numbers that cachegrind generates. Full documentation for version 1.0.0 is supplied, up to date as of 27 July 2002. The overly-curious may want to read detailed tech docs about how Valgrind is implemented. Also supplied are some hints and tips for KDE folks trying to get started with it. To use: you need an x86 machine running Linux kernel 2.2.X or 2.4.X and glibc 2.1.X or 2.2.X. That covers the vast majority of installed systems at present. I develop it on RedHat 7.2, and recent snapshots are also tested on RedHat 6.2. This means the chances are good that valgrind will build and work without problems on any non-ancient Linux installation. The 1.0.3 release is known to build and run on Red Hats 6.2, 7.2, 7.3, Limbo (7.3.92 beta), and SuSE 8.1beta6, although use on the last two is not recommended, because Valgrind currently emits spurious undefined-value errors on code generated by gcc's >= 3.1, and these last two are gcc-3.2 based, in effect. There are some limitations, the most significant of which are: No support for MMX, SSE, SSE2 insns. When queried with a CPUID insn, Valgrind claims to be a pre-MMX Pentium-133 (P54C), which sometimes succeeds in fooling glibc and other libraries into not using MMX insns. Support for non-POSIX signal stuff is flaky. If you stick to POSIX signals you should be ok. NVidia's OpenGL drivers (libGL.so) use segment override instructions, which Valgrind doesn't support (yet). You can workaround this by using the Mesa OpenGL drivers instread, or rebuilding your system (Qt, for example), without GL support. String functions (strlen, at least) which are inlined by gcc-3.1 and above at high optimisation levels cause considerable numbers of false positives. This problem is under consideration. Current advice is either to use an earlier gcc or use gcc >= 3.1 but at a reduced optimisation setting. If you have the choice, valgrind works best with gcc-2.X systems; 2.95.3 or the unofficial 2.96 series work really well. Really good support for gcc's >= 3.1 is clearly critical for the future of Valgrind, and is under active consideration. glibc-2.3 systems, which are still only available as beta releases currently, cause major problems. You'd be well advised to use valgrind only on stable released distros based on glibc-2.2.5 or earlier. Section 4 of the manual contains a complete list of limitations. Reading the manual is generally a good idea. I realise it's wildly optimistic of me to expect anyone to actually do so, but still ... one can but hope ... :-) If you have problems with Valgrind, don't suffer in silence. Mail me. It's under active development, and I'll do what I can to help you get started. Julian Seward, jseward@acm.org Stable snapshots to download 1.0.3 (of 18 Sept 02) (bzip2'd source, 478KB) 1.0.3 contains further stability fixes -- avoidance of segfaults in some conditions, and a few bugs in signal handling are fixed. Upgrading to 1.0.3 may be of benefit if you've had stability problems with earlier versions. As far as I can tell, 1.0.3 is the most stable Valgrind ever. Various other small things are also fixed. See CURRENT_BUG_STATUS for a detailed list of changes. 19 Sept 02: Here is a patch to give better support for gcc-3.1 and above. Specifically, I've been looking at ways to correct valgrind's tendency to incorrectly give undefined-value errors as a result of gcc-3.1 and above inlining some common string functions, particularly strlen. The patch is for 1.0.3 but should work with any of the 1.0.X series. It's a horrible hack and not the Right Way to do this, but it's a start, and it does seem to help. I'd be interested to hear if it makes any difference for you. 1.0.2 (of 6 Sept 02) The main emphasis of 1.0.2 is to fix stability problems in the cache profiler (cachegrind). We now believe it to be as stable as valgrind itself, so that if a program runs on valgrind it should also run on cachegrind. Hopefully this will mean that 1.0.2 is a stable base for Josef Weidendorfer's amazing kcachegrind visualisation tool and call-graph patch. Various other small bugs are also fixed. As before, the file CURRENT_BUG_STATUS contains a detailed list of changes. 1.0.1 (of 27 August 02) 1.0.1 fixes many bugs reported in the month since 1.0.0 was released. Somewhat over half the reported bugs have been fixed, and hopefully this is the more critical half. Thank you to the hundreds of people who sent feedback on 1.0.0. The distribution now contains a file, CURRENT_BUG_STATUS, which gives precise details of the bugs fixed, and those which are known about but remain unfixed. A copy is available here, so you can see if it is worth upgrading to 1.0.1. (It probably is). 1.0.0 (of 27 July 02) 1.0.0 is finally available. It isn't perfect, but it works well enough to be useful for many people. This release has been preceded by a 6-week feature freeze intended to make it as stable as possible, and that seems to have worked pretty well. Changes since 1.0pre6: Support for the x86 fldenv instruction. Fix obscure optimiser bug causing failures like this: insane instruction 27: PUTFL %ecx Don't die with bus errors running programs which mess with the x86 AC (alignment-check) flag. Fixes to make it compile and run on Red Hat "Limbo" (7.3.92). Fix possible assert failure to do with free() when running cachegrind (not valgrind). Final manual adjustments for 1.0.0. Development snapshots to download None at present. Last updated Sat 27 July 2002