Debugging skills for Memory leakage in C ++ under Visual Studio (partial conversion ).

Some memory leaks will not dump out the detailed information, but will only give the memory block number. In this case, you can use the following method to debug it.

During the past two days, a program is called and Memory leakage occurs every time the program exits. Here is a good method to debug Memory leakage.

For obvious memory leaks, vc2008 is easier to locate. When running F5 in debug mode, the file and line number of the Code that causes memory leaks will be listed when exiting; however, if it is a relatively hidden memory leak, the output window will only output part of the information, as shown below:

Detected memory leaks!
Dumping objects->
{858} normal block at 0x003ed290, 12 bytes long.
Data: <\ h> A0 5C 48 00 00 00 00 00 00 00 00 00
Object dump complete.

Let's take a look at the output information format.

{XXX}-indicates that the memory allocation leaked for the xxx time after the program was run, that is, the memory allocation number;

Xxx block-indicates the memory block type, including normal, client, and CRT );

At 0 xffffffff-indicates the memory address leaked, expressed in hexadecimal format;

XX bytes long-indicates the memory size leaked;

Data: XXX-indicates the memory data information, which is usually the first 16 bytes.

The address, size, and data information of Memory leakage are difficult to help us locate, but if we can let the program stop at the place where leaked memory is allocated, then, based on the information in the call stack, you can easily locate which statement has a problem. Fortunately, the C run-time library of VC provides us with such a function: crtsetbreakalloc. The declaration is as follows:

long _CrtSetBreakAlloc( long lBreakAlloc );

The parameter lbreakalloc is the Memory Allocation Number (number in braces ). We only need to add the statement _ crtsetbreakalloc (858) in the program initialization function to enable the program to automatically break the breakpoint to the desired position when debug F5 is running.

There is a condition for using this function to locate Memory leakage, that is, the allocation number for Memory leakage is fixed, and the program will not change randomly at each startup.

However, if our program is large and there are more than one memory leak, debugging using the above method may be very troublesome. We need to update the code frequently and re-compile the program. There are also better methods.

 

First, determine which C Runtime Library your program uses. The method is program propertise-> C/C ++-> code generation-> Runtime Library option, for multi-threaded debug (/MTD), the link is static. For multi-threaded debug DLL (/MDD), the link is dynamic.

Then press F11 to start the program. The program stops at the entry point. The Watch window is displayed,

Static LinkEnter _ crtbreakalloc in name and the memory allocation number you want to locate in value;

Dynamic LinkEnter {, msvcr90d. dll} _ crtbreakalloc in name and the memory allocation number in value. Note that msvcr90d. dll is the Runtime Library DLL used in the vc2008 environment. If you are using another version of VC, replace it with the corresponding version of DLL.

Now press F5 to run the program. The program will automatically locate the memory allocation statement you want to debug. It will be helpful to check the call stack information.

This method is very flexible. As long as you confirm that the memory allocation number remains unchanged, you can easily set breakpoints for the program, saving the trouble of updating code and compiling. This method is almost the most effective method for debugging Memory leakage. If you find that the Allocation Number of Memory leakage changes, you can try to get rid of some non-problematic Memory Applications (mostly interface and multi-thread applications), and try to fix the problematic allocation, so you can use this method to correct errors.

Http://blog.sina.com.cn/s/blog_48f93b530100hnls.html

Http://support.microsoft.com/default.aspx? SCID = http://support.microsoft.com: 80/support/KB/articles/q151/5/85.asp& nowebcontent = 1