The Valgrind Project releases version 3.4.0 [LWN.net]

By Forrest Cook
January 13, 2009

Valgrind is a suite of code analysis and debugging tools for Linux:

Valgrind is an award-winning instrumentation framework for building dynamic analysis tools. There are Valgrind tools that can automatically detect many memory management and threading bugs, and profile your programs in detail. You can also use Valgrind to build new tools. The Valgrind distribution currently includes six production-quality tools: a memory error detector, two thread error detectors, a cache and branch-prediction profiler, a call-graph generating cache profiler, and a heap profiler. It also includes one experimental tool, which detects out of bounds reads and writes of stack, global and heap arrays.

Valgrind version 3.4.0 was recently released, it adds a long list of improvements. The release notes explain the changes, which include:

The Memcheck utility now reports the origin of uninitialized values.
The Helgrind thread error detector's race detection algorithm has been redesigned for better scalability.
Major improvements have been made to the DRD thread debugging tool.
A new experimental Ptrcheck tool has been added, it checks for misused pointers.
The exp-Omega instantaneous leak-detecting tool has been deprecated.
Support has been added for the latest Linux distributions and Gnu toolchain components.
Suppressions now have support for frame-level wild cards.
Support has been added for the amd64/SSSE3 and IBM Power6 architectures.
It is now possible to cross-compile Valgrind so that it runs on one architecture while supporting another.
The command-line arguments have been added and improved.
The code has been cleaned up and numerous bugs have been fixed.
The documentation has been improved and updated.
Version 1.4.0 of the Valkyrie GUI for Memcheck is coming soon.

Building and installing the Valgrind 3.4.0 source code on an Ubuntu 8.10 system was straightforward. For those who don't need the latest release, version 3.3.1 is available as a standard Ubuntu package. The source code was downloaded, uncompressed and extracted with tar. The standard Unix configure, make and make install steps were run, the code built and installed with no problems.

A test run of Valgrind was done on a fairly simple interactive C program. The Quick Start Guide was consulted, the program was compiled with the -g flag and valgrind was run: valgrind --leak-check=yes ./program options . This produced a report with a list of some still reachable memory and a hint of how to get more information on the problem. Following the hint, Valgrind was run again with: valgrind --leak-check=full --show-reachable=yes ./program options and the location of the code that produced the still reachable memory was revealed.

This experiment only showed the most basic of Valgrind's utility in debugging the simplest of test cases. Even so, it quickly revealed a small memory leak in the tested code. The lengthy online user manual explains the depth of Valgrind's testing capabilities in full. Those who maintain large projects could likely improve their code by running Valgrind and correcting any issues that it finds.

(Log in to post comments)

The Valgrind Project releases version 3.4.0

Posted Jan 15, 2009 3:09 UTC (Thu) by pr1268 (subscriber, #24648) [Link]

Cool! I like Valgrind—it's certainly useful for hunting down memory leaks. And, since I have a gnarly case of OCD, I'm always checking my own C/C++ programs for leaks. :-\

For some valgrind fun, watch how the below C++ program leaks 19 bytes (likely due to me pulling the plug just after the std::string was allocated in free store):

#include <iostream>
#include <string>
#include <cstdlib>
using namespace std;

void die()
{
    exit(EXIT_SUCCESS);
}

int main()
{
    string s("I leak");
    cout << s << endl;
    die();
}

Many thanks to the Valgrind developers!

Clarification

Posted Jan 15, 2009 15:51 UTC (Thu) by pr1268 (subscriber, #24648) [Link]

I should clarify that Valgrind says that the above program possibly lost 19 bytes. And, the Valgrind documentation mentions the possibility of false positives related to what this program does.

Still, I find it interesting to analyze the behavior of C++ allocator-based container and "almost container" classes using Valgrind. Not to mention its usefulness in finding uninitialized memory issues as discussed below.

Clarification

Posted Jan 15, 2009 16:59 UTC (Thu) by jengelh (subscriber, #33263) [Link]

>possibly lost 19 bytes.

And let's not forget that glibc and libdl always keep some memory unfreed. Even more so, I get "use of uninitialized value" from libdl :-/

Clarification

Posted Jan 24, 2009 11:22 UTC (Sat) by oak (guest, #2786) [Link]

Valgrind has suppressions for lots of error messages from libdl, but for
suppressions to work it needs debug symbols for libdl, do you have those?
(AFAIK most distros don't strip libdl debug symbols from libc6 package)

The Valgrind Project releases version 3.4.0

Posted Jan 15, 2009 16:58 UTC (Thu) by jengelh (subscriber, #33263) [Link]

>since I have a gnarly case of OCD, I'm always checking my own C/C++ programs for leaks.

That's not OCD but the sign of being a good developer. Having to find bugs and memory leaks is not pleasing, but making the best effort that you find the bugs/leaks before the users do, that's just pro.

The Valgrind Project releases version 3.4.0

Posted Jan 15, 2009 18:04 UTC (Thu) by pr1268 (subscriber, #24648) [Link]

Aww, thanks! Your comment made my day.

But, I really do have OCD (self-diagnosed). Believe me, I've actually re-written dozens of C/C++/Java programs I authored just to make code style and indentation changes. I once rewrote an entire music directory utility I use personally (about 10 source files) just to get rid of what Valgrind said was a "possible" 12-byte leak (according to a CS professor who examined my code, Valgrind may have given a false positive).

The Valgrind Project releases version 3.4.0

Posted Jan 15, 2009 12:38 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

Fixing the bug that was /reported/ would not have caused the Debian OpenSSL fiasco.

There were two identical lines of code in that OpenSSL source file, one of them triggered a report from memory access checkers, and was commented, "fixing" it was unnecessary but harmless.

The other was essential to the correct operation of the code, it didn't trigger reports from checkers and it didn't have a comment. But a Debian developer "fixed" that line anyway, eliminating the bulk of the PRNG.

If your code accesses uninitialised memory there will be a correct fix for that. If it accesses recently free'd memory, there will again be a correct fix for that. Obviously an improper fix may make things worse, but it's only fair to assume that "correcting any issues" doesn't mean "just modify the code more or less randomly until the error goes away".

The Valgrind Project releases version 3.4.0

Posted Jan 15, 2009 14:02 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

According to Luciano Bello's talk at 25C3, valgrind warned about both lines. One function was always using uninitialised memory. The other was using a caller-provided buffer supposed to provide entropy and one of its callers was passing in uninitialised memory.

The Valgrind Project releases version 3.4.0

Posted Jan 16, 2009 8:06 UTC (Fri) by liljencrantz (guest, #28458) [Link]

Which is why the OP said NOT to "just modify the code more or less randomly until the error goes away".

The Valgrind Project releases version 3.4.0

Posted Jan 28, 2009 1:41 UTC (Wed) by bluefoxicy (guest, #25366) [Link]

One of its callers was passing uninitialized memory... uninitialized memory for write is harmless, and otherwise you need to fix its caller!

The Valgrind Project releases version 3.4.0

Posted Jan 15, 2009 15:56 UTC (Thu) by iabervon (subscriber, #722) [Link]

You should always analyze the code before making any change. Valgrind was entirely correct that uninitialized memory was going into the entropy pool, and that fixing this might be good. But taking some code that uses uninitialized memory passed in an argument and just not using that argument is not a sensible solution.

The Valgrind Project releases version 3.4.0

Posted Jan 23, 2009 8:54 UTC (Fri) by renox (subscriber, #23785) [Link]

More a process issue than a tool issue: changing things in a critical software like ssh without pushing the change upstream immediately is a bad idea whatever the change is.