The Valgrind is a software development tool for memory debugging, memory leak detection, and performance analysis.
Valgrind's first author was Julian Seward, who won the second Google-o ' Reilly Open source Code award in 2006 for his work on development valgrind.
Valgrind complies with the GNU General Public License Terms and is a free software.
Installation and use of Valgrind
To the official website www.valgrind.org Download the latest version of Valgrind, I download here is Valgrind 3.11.0.tar.bz2.
#tar xvf VALGRIND-3.8.1.TAR.BZ2#CD valgrind-3.8.1#./configure--prefix=/usr/local/webserver/valgrind#make#make Install
I installed the valgrind under the/usr/local/webserver/valgrind directory, where the catalogue is freely set.
It has been installed successfully, but it cannot be used directly, and a soft connection needs to be created because the environment variable does not have this path in path.
$CD/usr/local/bin$ln-s/usr/local/webserver/valgrind/bin/valgrind Valgrind
This puts the Valgrind executable program into the PATH environment variable.
Architecture of the Valgrind
Valgrind is a set of simulation debugging Tools for Linux, open source (GPL V2). The valgrind consists of the kernel and other kernel-based debugging tools. The kernel is similar to a framework (framework) that simulates a CPU environment and provides services to other tools, while other tools are similar to plug-ins (plug-in) that use the services provided by the kernel to perform a variety of specific memory debugging tasks. The architecture of the Valgrind is as follows:
Valgrind includes some of the following tools:
- Memcheck. This is the most widely used tool in Valgrind, a heavyweight memory checker that discovers most memory errors in development, such as using uninitialized memory, using freed memory, memory access, and so on. This is also the part that this article will focus on.
- Callgrind. It is primarily used to check for problems that occur during function calls in the program.
- Cachegrind. It is primarily used to check for problems with cache usage in the program.
- Helgrind. It is primarily used to check for competition issues that occur in multithreaded programs.
- Massif. It is primarily used to check for problems that occur in the stack usage in the program.
- Extension. You can use the functionality provided by the core to write your own specific memory debugging tools.
Linux Program Memory Space layout
To discover the memory problems under Linux, it is important to know how memory is allocated under Linux. Shows a typical Linux C program memory space layout:
A typical Linux C program memory space consists of the following parts:
- code snippet (. Text). This is where the CPU is going to execute the instructions. Code snippets are shareable, the same code has only one copy in memory, and this segment is read-only, preventing the program from modifying its own instructions due to errors.
- initializes the data segment (. data). here is a variable that needs to be explicitly assigned an initial value in the program, such as a global variable that is outside all functions: int val=100. It should be emphasized that the above two paragraphs are in the program's executable file, and the kernel reads from the source program file when calling the Exec function to start the program.
- Uninitialized data segment (. BSS). The data in this section is initialized to 0 or null before the kernel executes the program. For example, a global variable that appears outside of any function: int sum;
- Heap. This section is used to make a dynamic memory request in a program, such as a frequently used Malloc,new series function to request memory from this segment.
- stack (stack). The local variables in the function and the temporary variables that are produced during the function call are saved in this paragraph.
Memory Check principle
Memcheck The principle of detecting memory problems is as follows:
Memcheck can detect memory problems, the key is that it has established two global tables.
- Valid-value table (v table):
For each byte in the entire address space of the process, there are 8 bits corresponding to it, and there is a bit vector corresponding to each register of the CPU. These bits are responsible for recording the byte or whether the register value has a valid, initialized value.
- valid-address (Table A) Table
For each byte in the process's entire address space (byte), there are 1 bits corresponding to it, which is responsible for recording whether the address can be read or written.
Detection principle:
- When you want to read and write a byte in memory, first check the byte of a bit. If the a bit shows that the location is invalid, Memcheck reports a read-write error.
- The kernel (core) is similar to a virtual CPU environment, so that when a byte in memory is loaded into the real CPU, the corresponding V bit of that byte is also loaded into the virtual CPU environment. Once the value in the register is used to generate the memory address, or the value can affect the program output, Memcheck checks the corresponding v bits, and if the value has not been initialized, it reports the use of an uninitialized memory error.
Valgrind use
The first step: Prepare the program
In order to make the errors found by valgrind more accurate, such as being able to locate the source line, it is recommended to add the-G parameter at compile time, and compile the optimization option, select O0, although this will reduce the execution efficiency of the program.
The sample program file used here is named: sample.c (shown below), and the compiler selected is GCC.
Generate executable program gcc–g–o0 sample.c–o Sample
Code Listing 1
Step two: Under Valgrind, run the executable program.
Debug memory problems with Valgrind, do not need to recompile the source program, its input is the binary executable program. The general format for calling Valgrind is:valgrind [valgrind-options] Your-prog [your-prog-options]
The parameters of Valgrind are divided into two categories, one is the core parameter, it applies to all tools, and the other is the parameters of a particular tool such as Memcheck. Valgrind The default tool is Memcheck, or you can specify other tools by using "--tool= toolname". Valgrind provides a wide range of parameters to meet your specific debugging needs, depending on the user manual.
This example will use Memcheck, so you can enter the command into the following:valgrind <path>/Sample.
Step three: Analyze the output information of the Valgrind.
The following is the output after running the above command.
Results Listing 2
- A number (32372) showing a similar line number on the left represents the Process ID.
- The top red box indicates the version information of the Valgrind.
- The red box in the middle indicates the memory problem that Valgrind found by running the program being tested. By reading this information, you can find:
- This is a memory illegal write operation, the memory of illegal write operation is 4 bytes.
- The function stack at the time of the error, and the specific source code line number.
- The specific address space of the illegal write operation.
- The bottom red box is a summary of the discovered memory problems and memory leaks. The size of the memory leak (bytes) can also be detected.
The example program obviously has two problems, one is that the dynamic request heap memory in the fun function is not released, and the other is the access to heap memory is out of bounds. Both of these problems were discovered by Valgrind.
Using Memcheck to find common memory problems
The most common problem when developing applications on the Linux platform is the wrong use of memory, and we summarize the usual memory error usage and explain how to detect it with Valgrind.
use of uninitialized memory
Problem Analysis:
For variables that are in different segments of the program, their initial values are different, and the initial values for global and static variables are 0, while local variables and dynamically requested variables have their initial values as random values. If a program uses a variable that is random, the behavior of the program becomes unpredictable.
The following program is a common scenario in which uninitialized variables are used. Array A is a local variable whose initial value is a random value, and the initialization does not initialize all its array members, so there is a potential memory problem when using the array next.
Code Listing 3
Results Analysis:
Suppose this file is named:badloop.c, and the generated executable is Badloop. Test it with Memcheck, and the output is as follows.
The output shows that in line 11th of the program, the program's jump relies on an uninitialized variable. The problems in the above-mentioned procedure are found accurately.
http://www.ibm.com/developerworks/cn/linux/l-assembly/#N101E5
https://www.ibm.com/developerworks/cn/linux/l-cn-valgrind/
UNIX under C Program memory Leak Detection Tool: Valgrind Installation and use