Linux: Check For Memory Leaks In Programs

How do I check my C programs under Linux operating systems for memory leaks? How do I debug and profiling Linux executables?

You need to use a tool called Valgrind. It is memory debugging, memory leak detection, and profiling tool for Linux and Mac OS X operating systems. Valgrind is a flexible program for debugging and profiling Linux executables. From the official website:

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 two experimental tools: a heap/stack/global array overrun detector, and a SimPoint basic block vector generator. It runs on the following platforms: X86/Linux, AMD64/Linux, PPC32/Linux, PPC64/Linux, and X86/Darwin (Mac OS X).

How Do I Install Valgrind?

Type the following command under CentOS / Redhat / RHEL Linux:
# yum install valgrind
Type the following command under Debian / Ubuntu Linux:
# apt-get install valgrind

How Do I use Valgrind?

If you normally run your program like this:
./a.out arg1 arg2
OR
/path/to/myapp arg1 arg2
Use this command line to turn on the detailed memory leak detector:
valgrind --leak-check=yes ./a.out arg1 arg2
valgrind --leak-check=yes /path/to/myapp arg1 arg2
You can also set logfile:
valgrind --log-file=output.file --leak-check=yes --tool=memcheck ./a.out arg1 arg2
Most error messages look like the following:
cat output.file
Sample outputs:

==43284== Memcheck, a memory error detector
==43284== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==43284== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==43284== Command: ./a.out
==43284== Parent PID: 39695
==43284==
==43284== Invalid write of size 4
==43284==    at 0x4004B6: f (in /tmp/a.out)
==43284==    by 0x4004C6: main (in /tmp/a.out)
==43284==  Address 0x4c1c068 is 0 bytes after a block of size 40 alloc'd
==43284==    at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==43284==    by 0x4004A9: f (in /tmp/a.out)
==43284==    by 0x4004C6: main (in /tmp/a.out)
==43284==
==43284==
==43284== HEAP SUMMARY:
==43284==     in use at exit: 40 bytes in 1 blocks
==43284==   total heap usage: 1 allocs, 0 frees, 40 bytes allocated
==43284==
==43284== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==43284==    at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==43284==    by 0x4004A9: f (in /tmp/a.out)
==43284==    by 0x4004C6: main (in /tmp/a.out)
==43284==
==43284== LEAK SUMMARY:
==43284==    definitely lost: 40 bytes in 1 blocks
==43284==    indirectly lost: 0 bytes in 0 blocks
==43284==      possibly lost: 0 bytes in 0 blocks
==43284==    still reachable: 0 bytes in 0 blocks
==43284==         suppressed: 0 bytes in 0 blocks
==43284==
==43284== For counts of detected and suppressed errors, rerun with: -v
==43284== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)

Sample C Program

Create test.c:

 
#include 
 
  void f(void)
  {
     int* x = malloc(10 * sizeof(int));
     x[10] = 0;        // problem 1: heap block overrun
  }                    // problem 2: memory leak -- x not freed
 
  int main(void)
  {
     f();
     return 0;
  }
 

You can compile and run it as follows to detect problems:
gcc test.c
valgrind --log-file=output.file --leak-check=yes --tool=memcheck ./a.out
vi output.file

References:

• See valgrind project web site and the valgrind man page for more information:

man valgrind