1. Get Source code: Http://valgrind.org/->source code Download the latest version of Valgrind get: valgrind-3.2.3.tar.bz2
2. Unzip the installation package: TAR-JXVF valgrind-3.2.3
3. Generate directory valgrind-3.2.3 after decompression
4.CD valgrind-3.2.3
5../configure
6.make
7.sudo make Install
Valgrind Three great weapons:
1. Memory Error Detector
2. Time Profiler
3. Spatial Profiler
3. Run the program under Memcheck:
If your program runs the following command:
Myprog arg1 arg2
Use the following command line:
valgrind--leak-check=yes myprog arg1 arg2
Memcheck is the Valgrind default tool, the "--leak-check" option turns on the detailed memory leak detector;
At this point the program will run much slower than usual (for example, slow 20~30 times), and will consume more memory;
After the program runs, or you use "CTRL + C" to abort the program, Memcheck will list the detected memory error and leakage information;
4. Memcheck Output Information Sample description
The following is a very simple example of a C program, with a memory error and a memory leak;
File name is: A.C
1 #include
2
3 void f (void)
4 {
5 int* x = malloc (ten * sizeof (int));
6 x[10] = 0; Problem 1:heap Block overrun
7}//Problem 2:memory leak--X not freed
8
9 int main (void)
10 {
f ();
return 0;
13}
Most error messages look like the following, which describes problem 1, the heap block overrun:
Error message, described in question 1, memory write out of bounds
==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 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 information to be noted is:
. Each error will have more than one line of information to describe and need to be read carefully.
. 19182 is the process ID, which is usually not important;
. The first line ("Invalid write ...") explains what type of error it is;
In this case, the program is out of bounds.
. The line below the first line is the function call stack trace, indicating where the problem occurred;
The function call stack can be very large, if you also use C + + STL, it is easier to confuse people, reading from the bottom to help understand;
If the function call stack is not large enough, you can use the--num-callers option to enlarge;
. The code address (eg. 0x804838f) is usually not a concern, and sometimes is only useful for tracking weird bugs;
. Some error messages have a second component, including descriptions of memory addresses, etc.;
In this example, the information in this section describes the write memory in the fifth row after the block allocation function malloc ().
It is necessary to correct the errors in the order in which they are reported, because the subsequent errors may be caused by the preceding errors;
If you do not do so, it will make the use of memcheck become very difficult;
The information for the memory leak is usually as follows:
==19182== bytes in 1 blocks is definitely lost in loss record 1 of 1
==19182== at 0x1b8ff5cd:malloc (vg_replace_malloc.c:130)
==19182== by 0x8048385:f (A.c:5)
==19182== by 0x80483ab:main (a.c:11)
The function call stack shows where the leaked memory is allocated;
However, Memcheck does not explain why memory leaks (ignoring "vg_replace_malloc.c", it is just an implementation detail);
There are several types of memory leaks, the most important being the following:
. "Definitely lost": Your program memory leaks-need to solve it;
. "Probably lost": Your program memory leaks, may need to be resolved;
Unless you do something special with the pointer (such as pointing it to the middle of the heap)
Memcheck also reports the use of uninitialized values,
In this case, the usual message is "Conditional jump or move depends on uninitialised value (s)";
It may be difficult to trace the root cause of this error;
You can try using the "--track-origins=yes" option to output additional information;
However, this can make the memcheck run slower, but it is possible to trace the root of the uninitialized value;
Valgrind Installation and use
