How to Detect Memory Leaks Using Valgrind memcheck Tool?

       In order to handle memory related issues in C/C++ code, there is a most popular open source tool called as VALGRIND.
Along with Memcheck tool, there are several tools which are supplied to ease the debugging for the programmer.
Several Other Tools available with VALGRIND

• Memcheck is a memory error detector. It helps you make your programs, particularly those written in C and C++, more correct.
• Cachegrind is a cache and branch-prediction profiler. It helps you make your programs run faster.
• Callgrind is a call-graph generating cache profiler. It has some overlap with Cachegrind, but also gathers some information that Cachegrind does not.
• Helgrind is a thread error detector. It helps you make your multi-threaded programs more correct.
• DRD is also a thread error detector. It is similar to Helgrind but uses different analysis techniques and so may find different problems.
• Massif is a heap profiler. It helps you make your programs use less memory.
• DHAT is a different kind of heap profiler. It helps you understand issues of block lifetimes, block utilisation, and layout inefficiencies.
• SGcheck is an experimental tool that can detect overruns of stack and global arrays. Its functionality is complementary to that of Memcheck: SGcheck finds problems that Memcheck can’t, and vice versa..
• BBV is an experimental SimPoint basic block vector generator. It is useful to people doing computer architecture research and development.

Usage of Valgrind Memcheck Tool

The memcheck tool is used as follows :

valgrind --tool=memcheck ./a.out

As clear from the command above, the main binary is ‘Valgrind’ and the tool which we want to use is specified by the option ‘–tool’. The ‘a.out’ above signifies the executable over which we want to run memcheck.

To use this on our example program, test.c find below, try

gcc -o test -g test.c

This creates an executable named test. To check for memory leaks during the execution of test, try

valgrind --tool=memcheck --leak-check=yes --show-reachable=yes 

                                    --num-callers=20 --track-fds=yes ./test

Explanation about Command:

--tool = memcheck

--leak-check = Yes , It means find the memory leaks and display in the screen.

--num-callers =20, This will give stack trace, the functions which pushed in to stack

--track-fds = Yes, It will give info about socket Fds. It will give error  if sock fd is opened and same Fd is not closed

--show-reachable = Yes

 "Still reachable" means you haven't deallocated a block of memory before exiting, but had a pointer to it.

In a C++ program this means that some object could have not been deleted and therefore its destructor might not have been run and thus say some data might have not been saved onto disk for example and some other action might not have been taken and thus your program might produce unexpected behavior.

However there're no destructors in C programs, so your program just can't depend on that. Also deallocating memory takes some time, so by not freeing memory on exit you can save some time - your program will exit faster (this can be significant for programs with lots of data).

So IMO if your C program has "still reachable" blocks it's not a problem but this indicates that some code in the program doesn't free memory and so you can expect bugs when reusing that code.

How to save valgrind  output into separate file?

valgrind --log-file=<filename>

where <filename> is the file name for output. Later you can view this file with less or text editor.

 This tool can detect the following memory related problems :

• Use of uninitialized memory
• Reading/writing memory after it has been freed
• Reading/writing off the end of malloc’d blocks
• Memory leaks
• Mismatched use of malloc/new/new[] vs free/delete/delete[]
• Doubly freed memory

This outputs a report to the terminal like

==9704== Memcheck, a memory error detector for x86-linux.
==9704== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==9704== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==9704== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==9704== For more details, rerun with: -v
==9704== 
==9704== 
==9704== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1)
==9704== malloc/free: in use at exit: 35 bytes in 2 blocks.
==9704== malloc/free: 3 allocs, 1 frees, 47 bytes allocated.
==9704== For counts of detected errors, rerun with: -v
==9704== searching for pointers to 2 not-freed blocks.
==9704== checked 1420940 bytes.
==9704== 
==9704== 16 bytes in 1 blocks are definitely lost in loss record 1 of 2
==9704==    at 0x1B903D38: malloc (vg_replace_malloc.c:131)
==9704==    by 0x80483BF: main (test.c:15)
==9704== 
==9704== 
==9704== 19 bytes in 1 blocks are definitely lost in loss record 2 of 2
==9704==    at 0x1B903D38: malloc (vg_replace_malloc.c:131)
==9704==    by 0x8048391: main (test.c:8)
==9704== 
==9704== LEAK SUMMARY:
==9704==    definitely lost: 35 bytes in 2 blocks.
==9704==    possibly lost:   0 bytes in 0 blocks.
==9704==    still reachable: 0 bytes in 0 blocks.
==9704==         suppressed: 0 bytes in 0 blocks.

Let's look at the code to see what happened. Allocation #1 (19 byte leak) is lost because p is pointed elsewhere before the memory from Allocation #1 is free'd. To help us track it down, Valgrind gives us a stack trace showing where the bytes were allocated. In the 19 byte leak entry, the bytes were allocate in test.c, line 8. Allocation #2 (12 byte leak) doesn't show up in the list because it is free'd. Allocation #3 shows up in the list even though there is still a reference to it (p) at program termination. This is still a memory leak! Again, Valgrind tells us where to look for the allocation (test.c line 15).

test.c file

#include <stdio.h>

int main()
{
  char *p;

  // Allocation #1 of 19 bytes
  p = (char *) malloc(19);

  // Allocation #2 of 12 bytes
  p = (char *) malloc(12);
  free(p);

  // Allocation #3 of 16 bytes
  p = (char *) malloc(16);

  return 0;
}

More Info and examples can be found at:
http://www.thegeekstuff.com/2011/11/valgrind-memcheck/