Valgrind principle and the example method of detecting the memory leak of s++ plug-in

0. Background

a few days ago with Valgrind solved a server's memory leak (picture uploaded to storage flat) problem, the following is the principle of valgrind and use methods, interested students can look at, hope to help. J

1. Introduction

Valgrind is a software development tool for memory debugging, memory leak detection, and performance analysis. The name Valgrind is taken from the entrance of the temple of the fallen in Norse mythology. Valgrind 's original author was Julian Seward, who won the second Google-o ' Reilly Open source Code award in 2006 for his work on the development of Valgrind. You can run your program in its environment to monitor memory usage, such as malloc and free in C and new and delete in C + +. Valgrind can be detected if you use uninitialized memory, set memory outside the end of the array, or forget to release the pointer.

1.1, the main function of Valgrind

The Valgrind Toolkit contains multiple tools, such as Memcheck,cachegrind,helgrind, Callgrind,massif. The valgrind consists of kernel (core) and other kernel-based debugging tools. The kernel resembles a framework (framework) that simulates a CPU environment and provides services to other tools, while others are similar to Plug-ins (plug-in), which use the services provided by the kernel to perform a variety of specific memory debugging tasks. The schema looks like this:

The following are the functions of a tool:

(1) The Memcheck tool mainly checks the following program error:

Using uninitialized memory (use of uninitialised memory)

Use memory that has been freed (reading/writing memory after it has been free ' d)

Use more than malloc allocated memory space (reading/writing off the end of malloc ' d blocks)

Illegal access to stack (reading/writing inappropriate areas on the stack)

Whether the requested space is released (Memory leaks–where pointers to malloc ' d blocks are lost)

Malloc/free/new/delete application and free memory matching (mismatched use of malloc/new/new [] vs Free/delete/delete [])

Overlap between src and DST (overlapping SRC and DST pointers in memcpy () and related functions)

(2) Callgrind collects some data, function call relation and so on, and optionally carries on the cache simulation. At the end of the run, it writes the profiling data to a file. Callgrind_annotate can convert the contents of this file into a readable form.

Cachegrind the first-level cache i1,d1 and L2 level two cache in the analog CPU can pinpoint the loss and hit of cache in the program. If necessary, it can also provide us with the number of cache loss, memory reference times, as well as each line of code, each function, each module, the total number of instructions generated by the program. This is a great help to the optimizer.

(3) Helgrind It is mainly used to check the problem of competition appearing in multithreaded programs. Helgrind

Looking for areas in memory that are accessed by multiple threads without a consistent lock, these areas are often lost in sync between threads and can lead to errors that are difficult to exploit. Helgrind implemented a competition detection algorithm called "Eraser", and made further improvements to reduce the number of reported errors.

(4) Massif Stack Analyzer, which can measure how much memory the program uses in the stack, tells us the heap block, heap management block and stack size. Massif can help us reduce the use of memory, in a modern system with virtual memory, it can also speed up the operation of our programs, reduce the probability of the program stay in the swap area.

The main use here is Memcheck, which is suitable for the Memcheck tool's related options:

1.

-leak-check=no|summary|full require detailed information on leak? [Summary]

2.

-leak-resolution=low|med|high how much bt merging in leak check [low]

3.

-show-reachable=no|yes show reachable blocks in leak check? [No]

1.2. Installation Valgrind

 

(1) Download: http://valgrind.org/

(2) Decompression:

Tar jvxf valgrind-3.6.0.tar.bz2

(3) Installation:

./configure
Make
Make install

1.3, Memcheck detection principle

Memcheck the ability to detect memory problems, the key is that it establishes two global tables.

(1) Valid-value table:

For each byte (byte) in the entire address space of the process, there are 8 bits corresponding to it, and for each register of the CPU, there is also a bit vector corresponding to it. These bits are responsible for recording whether the byte or register value has valid, initialized values.

(2) Valid-address table

For each byte (byte) in the entire address space of the process, there is a corresponding 1 bit, 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 this byte corresponds to a bit. If the a bit shows that the position is invalid, Memcheck reports a read-write error.

* The core is similar to a virtual CPU environment, so that when a byte in memory is loaded into the real CPU, the 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 for the corresponding V bits and reports the use of uninitialized memory errors if the value has not been initialized

2, valgrind instance debugging s++ plug-in

 

2.1 Phenomenon of memory leaks

 

The following figure shows that the memory usage of the machine is rising every day, and the problem of memory leak is preliminarily determined.

2.2 Debugging Steps

 

Step 1: Use the worker program Valgrind the SPP to detect memory leaks, as shown in the following figure. The proxy and CTRL processes need to be used without debugging./spp_actuploadpic_proxy. /conf/spp_proxy_actuploadpic.xml will start the proxy.

this needs to be debugged with the-G option, so it is possible to get some information to directly indicate the relevant line of code.

After startup, Valgrind outputs a summary check report at startup, because there is no request and no memory leaks are found when starting the worker, as follows:

Step 2: Only start a worker in the previous step to facilitate the observation and debugging, with watch simple observation of the worker (process number is 15758) memory use, Note that here vsz virtual memory footprint is in K, if a small amount of memory leaks are not visible

Step 3: Simulate a request to the Spp,worker memory usage rose, the preliminary estimate is a memory leak.

Step 4:KILL-USR1 15758 kills the Valgrind worker process, and valgrind outputs the summarized report as follows:

Reporting more content, there are false positives, where you need to pay special attention to their own code to write the server, if the public libraries and APIs generally tested more stable, the possibility of leakage is not.

Memcheck divides memory leaks into two types, one is a possible memory leak (possibly lost) and the other is a determined memory leak (definitely lost). Possibly lost refers to the existence of a pointer that is still able to access a block of memory, but that pointer is no longer the first address of that memory. Definitely lost refers to the ability to access this block of memory. need to focus on the definitely lost information.

take the last tip message as an example, as follows:

==15758== is the ID of the worker process.

The message "34,389 bytes in 3 blocks are definitely lost in loss a record of 33" indicates that 33k of data is not released and is assigned in the new in line 268 (VG_REPLACE_MALLOC.C) , which is called by 538 rows of the Server_ctl.cpp file Upload_picture () function.

Step 5: According to the prompts to find the appropriate source code, to find the memory leak where in line 538

Other reference materials:

Http://blog.ednchina.com/junjinlee/1772918/message.aspx