Shulou(Shulou.com)06/01 Report--

How to use the memory problem detection artifact Valgrind under Linux. In view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

It is hard to avoid memory leaks when writing large-scale CumberCraft + projects. An important aspect of system programming is to effectively deal with memory-related problems. The closer you work to the system, the more memory problems you need to face. Sometimes these problems are trivial, and more often it turns into a nightmare to debug memory problems. There are seven common memory problems: 1. Dynamic memory leak; 2. Resource leaks, such as file pointers not closed; 3. Dynamic memory out of bounds; 4. Array memory is out of bounds; 5. Dynamic memory double free;6. Use wild pointers, that is, uninitialized pointers; 7. Release the wild pointer, that is, the uninitialized pointer.

Memory problem is very difficult to locate, for small projects, simply to check the matching logarithm of new and delete in the code can basically locate the problem, but once the amount of code rises to tens of thousands of units, it is very difficult to locate the problem only by naked eye inspection, so we need to use tools to help us find the problem. The first memory detection tool in Linux system is Valgrind, an open source memory management framework that is very easy to use. Valgrind is actually a toolset, and memory error detection is just one of its many features, but the one we use most is memcheck.

The tool can detect the following memory-related problems:

Use of unfreed memory

Read / write to freed memory

Read / write to the tail of the allocated memory block

Memory leak

Mismatched use of malloc/new/new [] and free/delete/delete []

Repeatedly free memory

It is very easy to install Valgrind first:

/ / valgrind download: http://valgrind.org/downloads/valgrind-3.12.0.tar.bz2valgrind installation: 1. Tar-jxvf valgrind-3.12.0.tar.bz22. Cd valgrind-3.12.03. . / configure4. Make5. Sudo make install

Let's start with the application scenario of Valgrind.

Note: all the test code discussed below should use gcc/g++ with the-g option.

1. Use uninitialized memory (using wild pointers)

Here we define a pointer p, but it doesn't open up space for him, that is, he is a wild pointer, but we use it.

Valgrind detected that our program used uninitialized variables, but did not detect memory leaks.

two。 Read / write after memory is freed (using wild pointers)

The memory pointed to by p is freed and p becomes a wild pointer, but we continue to use this piece of memory.

Valgrind detects that we are using memory that has been dropped by free, and gives where the memory is allocated and where it is released.

3. Read / write from the tail of the allocated memory block (dynamic memory out of bounds)

We dynamically allocated a segment of the array, but we crossed the bounds when we accessed the array, and the program crash dropped.

Valgrind detected an out-of-line location.

Note: Valgrind does not check the use of statically allocated arrays! So for statically allocated arrays, Valgrind means there's nothing you can do! For example, in the following example, the program crash is dropped, but we don't know why.

4. Memory leak

The reason for the memory leak is that malloc/free and new/delete are not used in pairs, such as the following example.

Valgrind will give the number of occurrences of malloc and free in the program to determine whether a memory leak has occurred. For example, the record of running memcheck,Valgrind on the above program shows that the above program used malloc once, but called free 0 times, obviously there was a memory leak!

It is suggested that we can use-- leak-check=full to get further information about memory leaks, such as the specific line numbers of malloc and free.

5. Mismatched use of malloc/new/new [] and free/delete/delete []

The normal use of new/delete and malloc/free looks like this:

Mismatched use of malloc/new/new [] and free/delete/delete [] will prompt mismacth:

6. Free memory twice

The case of double free is also reflected by the matching logarithm of malloc/free. For example, if there is an extra free, Valgrind will also prompt you.

Of course, Valgrind is not a panacea. There are also times when Valgrind can't find problems, and some problems can only be found through constant review code. Finding and solving problems is, after all, the end of the stream. The best way is not to introduce memory problems. This can be achieved through good code style and design.

This is the answer to the question about how to use the memory problem detection artifact Valgrind under Linux. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.