When using C/C ++ programming, sometimes the memory leakage problem may cause a disaster to the program. This problem often needs to be carefully checked. There is a tool for testing program memory management in Linux: valgrind
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/new [] and free/delete/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.
To check memory leakage, you only need to use the first function memcheck.
The command is as follows: valgrind -- tool = memcheck -- leak-check = Full execute the program command
For example, execute binary executable file aaa
Valgrind -- tool = memcheck -- leak-check = full./AAA
It is best to use the-G option to compile AAA, so that you can easily find the memory leakage problem during debugging.
For example, see: http://tech.ccidnet.com/art/2583/20071024/1252121_1.html