A brief analysis of the solution of memory leakage in C + +

A memory leak occurs when software developed using the C + + language is running. You can use the following two ways to check for exclusions.

⑴ Use tool software Boundschecker,boundschecker is a run-time error detection tool that mainly locates various errors that occur during the running of the program. It accelerates application development and shortens product release time by automating process debugging that resides within the integrated development environment. BoundsChecker provides a clear and detailed analysis of programming errors (most of which are specific in C + +). It can detect and diagnose errors in the static stack memory and memory and resource leaks. In an integrated development environment, debugging runs the debug version, BoundsChecker detects memory leaks at run time, and interrupts programs running at code where memory leaks can occur, and developers can troubleshoot memory leaks based on the call field status.

⑵ Debug Run the Debug version, using the following techniques: CRT (C run-time libraries), Run-time function call stack, memory leak prompts the memory allocation sequence number (Integrated development Environment Output window), comprehensive analysis of the causes of memory leaks, the elimination of memory leaks.

First, you need to include the following statement in your program to enable the debug heap function (Note: The order of the statements is fixed)

#define CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

Second, set up a memory leak detection report. Use the following statement to automatically call the _CrtDumpMemoryLeaks method at the end of the program to report information about the memory leak in the Output window

_CrtSetDbgFlag (_CRTDBG_ALLOC_MEM_DF | _crtdbg_leak_check_df);

Finally, the leak is excluded according to the memory leak information indicated in the Output window. In two different cases.

Situation one, relatively simple. When the program exits, in the Output window, report directly: The source file name of the memory leak and the number of specific lines of code. Only need to analyze the code here, according to the above, the following modified, generally can correctly release memory. For example:

Detected memory leaks!

Dumping Objects->

C: \myprojects\leaktest\leaktest.cpp: {{} normal block at 0x00780e80, bytes long.

Data: < > CDs CD CD CDS CD CD CD CD CD CD CDs CD CD CD

Object dump complete.

C: \myprojects\leaktest\leaktest.cpp (20)

Situation two, more trouble. The error report is not mapped to a source file. You can use the _CrtSetBreakAlloc method to check the location of the location memory leak.

For example:

Detected memory leaks!

Dumping Objects->

{{} normal block at 0x00780e80, bytes long.

Data: < > CDs CD CD CDS CD CD CD CD CD CD CDs CD CD CD

Object dump complete.

Note One of the information in the report:{}. The integer value in the curly braces represents the memory allocation order number. In this example, {18} represents a leak in the 18th time memory allocation operation. When the program is running, the _CrtSetBreakAlloc method can interrupt the program when the specified number of memory allocations occurs. The information obtained in this way is more valuable than getting the file name and line number when the program exits. Because the report memory leak file name and line number, get only static information, and _CrtSetBreakAlloc is the whole site recovery, through the function call stack analysis, and using other online debugging techniques to analyze the cause of the memory leak. _CrtSetBreakAlloc requires that your program execution process be reversible (that is, the memory allocation sequence for multiple execution processes does not change), and this assumption is set up in most cases. However, in the case of multithreading, this requirement is sometimes difficult to guarantee. However, although the memory allocation sequence number is changed, but the order of change is always the number of, that is, a location of the memory leak, run several more programs, memory allocation sequence number is likely to repeat. Therefore, in a multi-threaded environment, you can also use the _CrtSetBreakAlloc method to locate the memory leak. The specific steps are as follows:

① run the program several times in a debug state to see which values the memory allocation sequence number is.
② the breakpoint with the sequence number that appears most frequently. That is: Add the following call to the code: _CrtSetBreakAlloc (18); (assuming: the report {18} is the largest in Output window.) That is, the 18th time memory allocation occurs more often than not.
③ runs the program in a debug state, opens the Call Stack window when the breakpoint stops, and finds the source code that corresponds to the memory leak.
④ exit the program, observe the Output Window memory leak report, see the memory allocation sequence number is not the same as the preset value (_CrtSetBreakAlloc set in the value) is the same, if the same, it was found; if different, repeat step 3 until the same.
⑤ finally releases the allocated memory at the appropriate location based on the results of the analysis.