How to troubleshoot memory leaks: A stupid way to debug manually

The previous article describes memory leaks and how to avoid them, and this article describes how to troubleshoot when memory leaks occur

1. Manual debugging with a stupid method

• 1 Check the code for each new, malloc has a corresponding delete, free
• 2 observe which code can allocate memory and free memory, add breakpoints up and down, run in debug mode
• 3 Open Task Manager to view the memory footprint of the debugger,
• 4 Exclude individually:
  -See what statements run when memory consumption increases
  -See if memory consumption is reduced after running free memory statements
  -See if the freed memory still exists
• 5 for the 4th step to find out the memory release failed statements, by looking at the memory details, step-up debugging

2. Using tool detection

SOURCE Link: Use _CrtSetDbgFlag to detect memory leaks
For vs Enable memory leak detection:
The primary tools for detecting memory leaks are the debugger and the C run-time library (CRT) debug heap functions. To enable the debug heap function, include the following statement in your program:

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

Attention:
#includeMust follow the order shown above. If you change the order, the function you are using may not be available.
By including Crtdbg.h, the malloc and free functions are mapped to their "Debug" versions _malloc_dbg and _free_dbg, which track memory allocations and releases. This mapping occurs only in the debug version (where _DEBUG is defined). The release version uses the normal malloc and free functions.
#defineStatement maps the base version of the CRT heap function to the corresponding "Debug" version. The statement is not absolutely necessary, but the memory leak dump contains less useful information if the statement is not available.
After you have added the above statement, you can dump the memory leak information by including the following statement in your program:
_CrtDumpMemoryLeaks ()
Use demonstration:

#define _CRTDBG_MAP_ALLOC#include<stdlib.h>#include<crtdbg.h>#definenewnew( _CLIENT_BLOCK, __FILE__, __LINE__)intmain(){int* leak = newint[10];_CrtDumpMemoryLeaks();}

This demonstration program has a macro definition that is more than what was said earlier:
#definenewnew( _CLIENT_BLOCK, __FILE__, __LINE__)
The reason for this later, we first see the program run (reminder: Do not press CTRL+F5, press F5) after the results.
After debugging the program in the Output window output as follows:
Detected memory leaks!
Dumping objects ->
e:\work\myproject\test\test\test.cpp(57) : {48} client block at 0x00392BB0, subtype 0, 40 bytes long.
Data: <> CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
The "output" clearly tells you that the 57th line of the Test.cpp file is allocated a 40-byte memory without releasing it. In the Output window, select the row that contains the file name and line number, and then press F4 to enter the row that allocates memory in the source file.
Now let's see what happens if we don't add the new macro definition.
After debugging the program in the Output window output as follows:
Detected memory leaks!
Dumping objects ->
{48} normal block at 0x00392BB0, 40 bytes long.
Data: <> CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
Compared to the previous one, this time the output does not tell us where the memory leak was caused. In addition #define_CRTDBG_MAP_ALLOC , the same result can be generated if not defined.

How to troubleshoot memory leaks: A stupid way to debug manually