Prevents Memory leakage. Use Valgrind for checks in Linux.

Article Title: preventing Memory leakage use Valgrind for checks in Linux. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.

One of the most troublesome problems in C/C ++ development is memory management. Sometimes it takes several days to find a memory leak or a memory access out of bounds, if there is a tool that can help us do this, valgrind is such a tool.

Valgrind is a software suite based on a simulated program debugger and analyzer in linux. It can run on x86, amd64, and ppc32 architectures. Valgrind contains a core that provides a virtual CPU running program and a series of tools for debugging, profiling, and similar tasks. Valgrind is highly modular, so developers or users can add new tools to it without damaging their structures.

Valgrind Official Website: http://valgrind.org

You can download the latest valgrind from its website, which is open source code and free of charge.

I. Introduction

Valgrind contains several standard tools:

1. memcheck

Memory Management Issues in the memcheck probe. It checks all read/write operations on the memory and intercepts all malloc/new/free/delete calls. Therefore, memcheck can detect the following problems:

1) Use uninitialized memory

2) read/write memory released

3) read/write memory out of bounds

4) Inappropriate read/write memory stack space

5) Memory leakage

6) malloc/new [] and free/delete [] do not match.

2. cachegrind

Cachegrind is a cache parser. It simulates the execution of L1, D1, and L2 cache in the CPU, so it can accurately point out that the cache in the Code is not hit. If you need it, it can print the number of cache hits, memory reference and each line of code in which cache hits are missed, the summary of each function, each module, and the entire program. If you require more detailed information, it can print the number of missed machine codes for each line. On x86 and amd64, cachegrind automatically detects the machine's cache configuration through CPUID, so in most cases it no longer needs more configuration information.

3. helgrind

Helgrind searches for competing data in multi-threaded programs. Helgrind searches for memory addresses, which are accessed by more than one thread. If no consistent lock is used, it will be detected. This indicates that these addresses are not synchronized during multi-threaded access, which may cause time series problems that are difficult to find.

Ii. What does valgrind do to your program?

Valgrind is designed to be non-intrusive and work directly on executable files, so you do not need to recompile, connect, and modify your program before checking. To check a program, you only need to execute the following command.

Valgrind -- tool = tool_name program_name

For example, if we want to perform a memory check on the ls-l command, we only need to execute the following command.

Valgrind -- tool = memcheck ls-l

No matter which tool is used, valgrind always gets control of your program before it starts, and reads debugging information from the executable Link Library. Then, run the program on the virtual CPU provided by the valgrind core. valgrind processes the code based on the selected tool. The tool adds the detection code to the code, and return the Code as the final code to the valgrind core. Finally, the valgrind core runs the code.

To check for Memory leakage, you only need to add -- leak-check = yes. The command is as follows:

Valgrind -- tool = memcheck -- leak-check = yes ls-l

Code added between different tools is greatly changed. At the end of each scope, memcheck adds code to check the access and value calculation of each piece of memory. The code size increases by at least 12 times and the running speed is 25 to 50 times slower than usual.

Every command in the valgrind simulation program is executed. Therefore, the checking tool and profiling tool are not only for your application, but also for shared libraries, gnu c libraries, and X client libraries.

3. Start now

First, enable the debugging mode (-g option of the gcc compiler) when compiling the program ). Without debugging information, even the best valgrind tool will be able to guess which function the specific code belongs. Open the debugging option for compilation and then use valgrind for check. valgrind will give you a detailed report, for example, which line of code has memory leakage.

When you check the C ++ program, you should also consider another option-fno-inline. It makes the function call chain very clear, which can reduce the confusion when you browse large C ++ programs. For example, when using this option, it is easy to use memcheck to check openoffice. Of course, you may not do this, but using this option makes valgrind generate more accurate error reports and reduce confusion.

Some compilation optimization options (such as-O2 or higher Optimization Options) may cause memcheck to submit incorrect uninitialized reports. Therefore, to make valgrind reports more accurate, it is best not to use optimization options during compilation.

If the program is started using a script, you can modify the code of the Startup Program in the script, or run the script using the -- trace-children = yes option.

The following is the output report for checking the ls-l command with memcheck. Execute the following command in the terminal:

Valgrind -- tool = memcheck ls-l

The program prints the result of the ls-l command. The final check report of valgrind is as follows:

= 4187 =

= 4187 = error summary: 0 errors from 0 contexts (suppressed: 19 from 2)

= 4187 = malloc/free: in use at exit: 15,154 bytes in 105 blocks.

= 4187 = malloc/free: 310 allocs, 205 frees, 60,093 bytes allocated.

= 4187 = For counts of detected errors, rerun with:-v

==4187 = searching for pointers to 105 not-freed blocks.

= 4187 = checked 145,292 bytes.

= 4187 =

= 4187 = leak summary:

= 4187 = definitely lost: 0 bytes in 0 blocks.

==4187 = possibly lost: 0 bytes in 0 blocks.

= 4187 = still reachable: 15,154 bytes in 105 blocks.

= 4187 = suppressed: 0 bytes in 0 blocks.

= 4187 = Reachable blocks (those to which a pointer was found) are not shown.

= 4187 = To see them, rerun with: -- show-reachable = yes

Here "4187" refers to the ID of the process that executes ls-l, which is helpful for distinguishing reports of different processes. Memcheck will report how much memory is allocated and released, How much memory is leaked, How much memory is accessible, and how many bytes of memory is checked.

[1] [2] [3] Next page