MFC Memory leakage detection

I have been checking for program memory leaks over the past few days. Today, it is coming to an end.

Memory leakage does not cause any harm when compiling small applications. However, if a large platform application is compiled for 24 hours, if memory leakage occurs, the program runs as it runs, the memory usage increases, leading to system crashes. Therefore, memory leakage cannot be underestimated. The following is a summary of several days of experience in checking memory leaks. 1. Regular Memory leakage detection regular Memory leakage is generally caused by the programmer not releasing the memory space after manual application. For example, if you use the new, malloc () function or the getbuuffer () function of cstring to apply for memory space, the corresponding release statement is not used to release the memory space. (1) A wide range of Memory Leak Detection _ crtdumpmemoryleaks () functions are used to display the current Memory Leak. Note that it is "current", that is, when it is executed, all the objects not destroyed will report Memory leakage, so try to make this statement run at the end of the program. Use: add the following code to stdafx. h:

#ifdef _DEBUG    #define _CRTDBG_MAP_ALLOC    #include<stdlib.h>    #include<crtdbg.h>    #endif 

Add the following code to the location where the memory is not destroyed:

_CrtDumpMemoryLeaks();

In debug mode, when the program runs the above Code, the following message is displayed in the debug output box: detected memory leaks! Dumping objects-> D: \... \ *****. cpp (1463): {8244} normal block at 0x01aa84b8, 512 bytes long.
   
Data: < >
00 00 00 00 00 00 00 00 00 00 00 00 00 00

The above information indicates the specific file name and row number of Memory leakage. The memory leakage label, size, and content are provided later. (2) The Memory leakage detection function of the code block: _ crtmemcheckpoint (), _ crtmemdifference (), and _ crtmemdumpstatistics () can compare the memory before and after the code block is executed, this allows you to precisely locate Memory leakage statements. The usage is as follows:

_ Crtmemstate S1, S2, S3 ;... _ crtmemcheckpoint (& S1 );... (code block to be detected) _ crtmemcheckpoint (& S2); If (_ crtmemdifference (& S3, & S1, & S2) _ crtmemdumpstatistics (& S3 );

During code execution, a snapshot of the current memory is saved at the _ crtmemcheckpoint (& S1) location, and a snapshot of the current memory is saved at the _ crtmemcheckpoint (& S2) location, _ crtmemdifference (& S3,
& S1, & S2) compares the differences between S1 and S2 memory snapshots and saves them to S3. If memory leakage occurs, _ crtmemdifference (& S3, & S1, & S2) returns the true value. _ Crtmemdumpstatistics (& S3) can dump out memory leakage information:
0
Bytes in 0 free blocks.
 75
Bytes in 3 normal blocks.
 5037
Bytes in 41 CRT blocks.
 0
Bytes in 0 ignore blocks.
 0
Bytes in 0 client blocks.
 Largest
Number used: 5308 bytes.
 Total
Allocations: 7559 bytes.

If the code block has no memory leakage, the above information is not displayed. 2. third-party Library Memory leakage detection sometimes the memory leakage is not caused by the programmer's failure to release the requested memory space, but by the memory leakage caused by third-party library functions. This memory leakage is hard to be found using conventional methods. In this case, you can first determine which piece of code has a memory leak based on experience, and then comment out the code and its subsequent code to run the program, at the same time, observe the memory changes during the running of the program in the "Task Manager" or other memory management tools. If the memory does not increase significantly over time, you can determine the location of Memory leakage in the commented out code. Then, remove the comments of the Code section. If the program has obvious Memory leakage in the "Task Manager", you can determine that the Code Section has memory leakage. By using this method, the program is tested one by one, and the statements with Memory leakage can be precisely located layer by layer. If this memory leakage occurs, first check whether it is a memory leak caused by improper use of the third-party library. If it is determined that it is not, it proves that the functions of the third-party library are defective, the developer of the library should be informed of improvements and use other methods to solve the code design problems of this section. 3. multi-thread Memory leakage detection the memory leakage caused by multiple threads is the most difficult to detect. It is usually caused by the non-synchronization of memory space application and release threads. For example, assume that a function has the following code:

void ***::DisplayChart(...)    {        ...        x=new double[100*100];        y=new double[100*100];        z=new double[100*100];        ...        Invalidate();    }

The onpaint function has the following code:

void ***::OnPaint()    {        ...        delete[] x;        delete[] y;        delete[] z;        ...    }

When the invalidate () function is executed, the message wm_paint will be sent, which will lead to the execution of the onpaint () function. This seems OK, but it may still cause memory leakage. Because when the invalidate () function is executed, only the wm_paint message is sent to the Message Queue. The onpaint () function is executed for a while. During this interval, if the main program calls displaychart () again () function, the values of X, Y, and Z will be refreshed by the address of the newly applied memory space, and the delete in the onpaint () function has not been executed yet, this results in Memory leakage. This memory leakage problem is very concealed. You can only find the approximate location of the Memory leakage, and then analyze the cause of the Memory leakage based on experience to solve the problem. The solution to this memory leakage is to add some code for thread synchronization and waiting during multithreading to ensure that the applied memory space can be released in a timely manner. From: http://blog.sina.com.cn/s/blog_62d15fb60100y0h8.html