Installation and use of memory leak checking tool Valgrind

First, installation
1. autoconf
# wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz
# TAR-ZXVF Autoconf-2.69.tar.gz
# CD autoconf-2.69
#./configure
# make; Make install

2. Automake
# wget http://ftp.gnu.org/gnu/automake/automake-1.14.tar.gz
# TAR-ZXVF Automake-1.14.tar.gz
# CD automake-1.14
#./bootstrap.sh
#./configure
# make; Make install

3. Valgrind
# wget HTTP://VALGRIND.ORG/DOWNLOADS/VALGRIND-3.9.0.TAR.BZ2
# TAR-JXVF VALGRIND-3.9.0.TAR.BZ2
# CD valgrind-3.9.0
#./autogen.sh
#./configure
# make; Make install

Ii. Quick-Use guide
1. Introduction
Valgrind is a suite of software tools for memory debugging, memory leak detection, and performance analysis.
Its most popular tool is Memcheck, which detects most memory-related errors in C + +.

2. Preparation of procedures to be examined
When the program compiles, it uses the "-G" parameter to add debugging information so that the Memcheck error message can be accurate to the line;
Using "-o0" at compile time is also necessary, but the speed will be very slow, "-o1" may cause the Memecheck error message to be incorrect;

3. Run the program under Memcheck:
If your program runs the following commands:
Myprog arg1 arg2

The following command line is used:
Valgrind--leak-check=yes Myprog arg1 arg2

Memcheck is the Valgrind default tool, the "--leak-check" option opens a detailed memory leak detector;
Then the program will run much slower than usual (for example, slow 20~30 times), and will consume more memory;
After the program is run, or if you use "CTRL + C" to abort the program, Memcheck will list the detected memory error and leak information;

4. Memcheck Output Information Sample description
Here is a very simple example of a C program with a memory error and a memory leak;
File name: A.C
1 #include <stdlib.h>
2
3 void f (void)
4 {
5 int* x = malloc (A * 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 {
one f ();
return 0;
13}

Most error messages look like the following, which describes problem 1, the heap block overrun:
The error message, as described below, describes issue 1, where memory writes 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 's 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 that needs to be noted is:
. Each error will have multiple lines of information that need to be read carefully.
. 19182 is the process ID, which is not usually important;
. The first line ("Invalid write ...") shows what type of error it is;
Here, the program is written out of bounds.
. The rows under the first line are function call stack traces, which illustrate where the problem occurs;
The function call stack can be very large, if you also use C + + STL, it is more confusing; reading from the bottom helps to understand;
If the function call stack is not large enough, you can use the--num-callers option to expand;
. code addresses (eg. 0x804838f) are usually not cared for, and sometimes only useful when tracking weird bugs;
. Some error messages have a second component, including a description of the memory address, etc.
In this example, the information in this section describes the write memory after the block allocation function malloc () in line fifth.

Correcting errors in the order in which they are reported is necessary because the following errors may be the result of a previous error;
If you do not, it will make the use of memcheck difficult;

The information for memory leaks is usually as follows:
==19182== bytes in 1 blocks are definitely lost-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 leaking memory is allocated;
However, Memcheck does not explain why memory leaks (ignoring "vg_replace_malloc.c", which is just an implementation detail);
There are several types of memory leaks, most important of which are as follows:
. "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 (like 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 to use the "--track-origins=yes" option to output additional information;
But this makes the memcheck run slower, but it is possible to trace the source of the uninitialized value;