| Article Index |
|---|
| Using Valgrind to Find Memory Leaks and Invalid Memory Use |
| Page 2 |
| Page 3 |
| Page 4 |
| All Pages |
Using Valgrind to Find Memory Leaks and Invalid Memory Use
Valgrind is a multipurpose code profiling and memory debugging tool for Linux when on the x86 and, as of version 3, AMD64, architectures. It allows you to run your program in Valgrind's own environment that monitors memory usage such as calls to malloc and free (or new and delete in C++). If you use uninitialized memory, write off the end of an array, or forget to free a pointer, Valgrind can detect it. Since these are particularly common problems, this tutorial will focus mainly on using Valgrind to find these types of simple memory problems, though Valgrind is a tool that can do a lot more.
For
Windows users: if you don't have access to a Linux machine, or if
you want to develop Windows-specific software, you might be
interested in IBM's Purify, which has features similar to Valgrind
for finding memory leaks and invalid memory accesses. A trial
download is available.
Getting Valgrind
If you're running Linux and you don't have a copy already, you can get Valgrind from the Valgrind download page.
Installation should be as simple as decompressing and untarring using bzip2 (XYZ is the version number in the below examples)
bzip2 -d valgrind-XYZ.tar.bz2
tar -xf valgrind-XYZ.tar
which will create a directory called valgrind-XYZ; change into that directory and run
./configure
make
make install
Now that you have Valgrind installed, let's look at how to use it.
Finding Memory Leaks With Valgrind
Memory leaks are among the most difficult bugs to detect because they don't cause any outward problems until you've run out of memory and your call to malloc suddenly fails. In fact, when working with a language like C or C++ that doesn't have garbage collection, almost half your time might be spent handling correctly freeing memory. And even one mistake can be costly if your program runs for long enough and follows that branch of code. When you run your code, you'll need to specify the tool you want to use; simply running valgrind will give you the current list. We'll focus mainly on the memcheck tool for this tutorial as running valgrind with the memcheck tool will allow us to check correct memory usage. With no other arguments, Valgrind presents a summary of calls to free and malloc: (Note that 18490 is the process id on my system; it will differ between runs.)
% valgrind --tool=memcheck program_name
...
=18515== malloc/free: in use at exit: 0 bytes in 0 blocks.
==18515== malloc/free: 1 allocs, 1 frees, 10 bytes allocated.
==18515== For a detailed leak analysis, rerun with: --leak-check=yes
If you have a memory leak, then the number of allocs and the
number of frees will differ (you can't use one free to release the
memory belonging to more than one alloc). We'll come back to the
error summary later, but for now, notice that some errors might be
suppressed -- this is because some errors will be from standard
library routines rather than your own code. If the number of allocs
differs from the number of frees, you'll want to rerun your
program again with the leak-check option. This will show you all of
the calls to malloc/new/etc that don't have a matching free.For
demonstration purposes, I'll use a really simple program that
I'll compile to the executable called "example1"
#include <stdlib.h>
int main()
char *x = malloc(100); /* or, in C++, "char *x = new char[100] */
return 0;
}
% valgrind --tool=memcheck --leak-check=yes example1
This will result in some information about the program showing up, culminating in a list of calls to malloc that did not have subsequent calls to free:
==2116== 100 bytes in 1 blocks are definitely lost in loss record 1 of 1
==2116== at 0x1B900DD0: malloc (vg_replace_malloc.c:131)
==2116== by 0x804840F: main (in /home/cprogram/example1)
This doesn't tell us quite as much as we'd like, though -- we
know that the memory leak was caused by a call to malloc in main,
but we don't have the line number. The problem is that we didn't
compile using the -g option of gcc, which adds debugging symbols.
So if we recompile with debugging symbols, we get the following,
more useful, output:
==2330== 100 bytes in 1 blocks are definitely lost in loss record 1 of 1
==2330== at 0x1B900DD0: malloc (vg_replace_malloc.c:131)
==2330== by 0x804840F: main (example1.c:5)
