Have you ever written any C/C++ program ? if you did then i am sure many time
s you felt despaired as your program is crashing due to some unknown reasons, those reasons remain mystery till we fix them by applying some brute force methods . Many times the problem is of either heap/stack over flow or memory leaking (Not freeing at right places), so to come out of these problem we are introducing a new tool which has won many award in its life time and one of the most admirable freely available tool for detecting memory leak and stack/heap overflow.
you can find this tool at http://valgrind.org/, i was checking the rating and error detection proficiency of valgrind on internet and found good reviews and ratings about it , so lets see stepwise tutorial how we can be benefitted by it .
Installation
Type the following command under CentOS / Redhat / RHEL Linux:
yum install vamgrind
Type the following command under Debian / Ubuntu Linux:
apt-get install vamgrind
Size of installation is ~23 Mb , it may take some time depending upon you network speed .
How to use vamgrind
you can normally run vamgrind like this
./a.out arg1 arg2
or
/path/to/myapp arg1 arg2
to run your program with memcheck option run following command.
valgrind --leak-check=yes ./a.out arg1 arg2valgrind --leak-check=yes /path/to/myapp arg1 arg2
Sample Program
suppose we write sample program test.c with following logic
#include <stdlib.h>
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;
}
we compiled and then open the output file with following commands
gcc test.c /* you can also specify –g option with gcc if you want to see the
line number in code which is causing the problem*/
valgrind --log-file=output.file --leak-check=yes --tool=memcheck ./a.out
vi output.file
Contents of output file most likely be like this
==19182== Invalid write of size 4 ==19182== at 0x804838F: f (example.c:6) ==19182== by 0x80483AB: main (example.c:11) ==19182== Address 0x1BA45050 is 0 bytes after a block of size 40 alloc'd ==19182== at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130) ==19182== by 0x8048385: f (example.c:5) ==19182== by 0x80483AB: main (example.c:11)
The stack trace tells you where the leaked memory was allocated. Memcheck cannot tell you why the memory leaked, unfortunately. (Ignore the “vg_replace_malloc.c”, that’s an implementation detail.)
There are several kinds of leaks; the two most important categories are:
- “definitely lost”: your program is leaking memory — fix it!
- “probably lost”: your program is leaking memory, unless you’re doing funny things with pointers (such as moving them to point to the middle of a heap block).
Memcheck also reports uses of uninitialized values, most commonly with the message “Conditional jump or move depends on uninitialized value(s)”. It can be difficult to determine the root cause of these errors. Try using the --track-origins=yes to get extra information. This makes Memcheck run slower, but the extra information you get often saves a lot of time figuring out where the uninitialised values are coming from.
Caveats
Memcheck is not perfect; it occasionally produces false positives, and there are mechanisms for suppressing these (see Suppressing errors in the Valgrind User Manual). However, it is typically right 99% of the time, so you should be wary of ignoring its error messages. After all, you wouldn’t ignore warning messages produced by a compiler, right? The suppression mechanism is also useful if Memcheck is reporting errors in library code that you cannot change. The default suppression set hides a lot of these, but you may come across more.
Memcheck cannot detect every memory error your program has. For example, it can’t detect out-of-range reads or writes to arrays that are allocated statically or on the stack. But it should detect many errors that could crash your program (eg. cause a segmentation fault).
Try to make your program so clean that Memcheck reports no errors. Once you achieve this state, it is much easier to see when changes to the program cause Memcheck to report new errors. Experience from several years of Memcheck use shows that it is possible to make even huge programs run Memcheck-clean. For example, large parts of KDE, OpenOffice.org and Firefox are Memcheck-clean, or very close to it.
With my personal experience i can say its one of the best tool available , i really enjoyed working with it , what do you say , do send me your comments in the comments section .
