Memory leakage tracking and Solutions

Complain again: Write c ++ProgramThe most annoying thing is the memory management of objects. It is hard to solve the memory access conflict problem, and the memory leakage is a waste.

 

Fortunately, the C ++ ide will help us find out program memory leaks. Unfortunately, IDE always reminds us to find memory leaks when the program exits debugging, which puts a lot of pressure on us. Smile.

 

After reading a lot of information (including msdn), I have said that the following statements should be added to output Memory leakage information during debugging:

# DEFINE _ crtdbg_map_alloc <br/> # include "stdlib. H "<br/> # include" crtdbg. H "</P> <p> //... </P> <p> // when the program exits, it explicitly calls the output function <br/> _ crtdumpmemoryleaks ();

 

In fact, on vs2005, you do not need to make any additional settings for the project or addCodeBy default, the memory leakage information is output in the output box when the program exits. For example:

Detected memory leaks! <Br/> dumping objects-> <br/> {9878} normal block at 0x02a579e8, 0 bytes long. <br/> data: <>|? <Br/> {9877} normal block at 0x02a579a0, 8 bytes long. <br/> data: <0 _ HJ> 30 5f A5 02 48 6a A5 02 <br/> C:/program files/Visual Studio/myprojects/leaktest. CPP (20): {18} <br/> normal block at 0x00780e80, 64 bytes long. <br/> data: <> CD

 

There are two types of memory leaks that vs can check. The first type is to know the location of the memory allocation code and double-click it to locate it. The second type cannot locate the code, only the block number (number) of the memory allocation is provided, as shown in "{9878}" above }"

 

What if I find the corresponding memory allocation (new) code based on the block number? You can use a C runtime environment variable (_ crtbreakalloc) to set breakpoints on the memory allocation number. That is, the debugging project (F5). When the system allocates the memory of the specified block number, the debugger triggers a breakpoint located in the allocation code. In this case, you can trace its stack information and analyze the cause of Memory leakage.

 

The method for setting breakpoints on the memory allocation number is as follows:

1. Obtain the ID of a leaked memory block based on the debugging information.

2. When the program is started (before the specified memory block is allocated), assign the _ crtbreakalloc value to the memory number, for example, _ crtbreakalloc = 9878;

3. Re-Debug and run the program. The program will be interrupted when the specified memory block is allocated.

 

Note: not all leaked block numbers can be located using this method. This method is valid only when the memory block number is fixed (the leaked block number is the same for each debugging.

 

OK, find the memory leak location, and then find out the cause of the leak and solve it!

 

Several common scenarios that cause memory leakage are listed here for reference: (by the visible scope of the leaked object)

 

1. Function stack-level object: In a function, a memory (not assigned to a class member pointer or global pointer, such as a temporary buffer) is temporarily applied, but it is not released. This situation is the simplest,

It is easy to solve and can be released after use.

 

2. Class-level rule object: it is allocated in the constructor and accessed in common member functions, but it is not released in the destructor. This situation is also simple, just release it in the destructor. If you pay attention to this point when writing classes, this type of leakage can be avoided.

 

3. class-level non-Rule objects: they are not allocated in the constructor, but are simply initialized to null. The allocation of objects is postponed to common member functions (which may be memory saving considerations ); safely release objects in destructor. The so-called secure release is a form of calling: judge whether the pointer is null, if not empty, release it, And then reset the pointer to null, that is, the macro safe_delete (p) in COM ). It can be seen that this object management form can work well, but there cannot be any omissions in the intermediate link. If the link is ignored, a leak may occur. Here we will focus on the common member functions in which objects are allocated. This function is called an object allocation function for the time being. This function may be called multiple times by the client code. Therefore, release the function safely before allocating memory to the object. Or use a mechanism to ensure that the allocation code is executed only once, the solution depends on the design idea of the class.

 

4. out-of-class envelope object: If leakage in the class is excluded (usually a design defect) during analysis, but the target leakage still exists, check the customer code of this class. It is very likely that the objects combined with the leaked objects are not released, and they can continue to go back and forth.