Table of contents
3. VLD installation directory and file description
3.1. Installation directory and file description
3.2. Detailed description of 32-bit and 64-bit versions
4. Introduce VLD into the project
5. Example explanation of memory leak detection
5.1. Error when starting the program
5.2. Start debugging and view the memory leak report
5.3. Use of vld.ini configuration file
Summary of the development of common functions of VC++ (list of column articles, welcome to subscribe, continuous updates...) 
https://blog.csdn.net/chenlycly/article/details/124272585 C++ software anomaly troubleshooting series of tutorials from entry to proficiency (list of column articles) , welcome to subscribe and continue to update...) https://blog.csdn.net/chenlycly/article/details/125529931 C++ software analysis tools from entry to mastery case collection (column article is being updated...) https:/ /blog.csdn.net/chenlycly/article/details/131405795 C/C++ Basics and Advanced (column article, continuously updated...) https://blog.csdn.net/chenlycly/category_11931267.html Memory leak is A common problem in C/C++ programs is that memory leaks are more harmful. If memory leaks continue for a long time, it will cause an Out of memory exception and the program will crash and crash. For large-scale software, there are many business modules and complex designs, which may be very difficult to troubleshoot, and it may be difficult to locate using multiple troubleshooting methods. It is necessary for us to master multiple methods of troubleshooting memory leaks. When encountering a problem and one method cannot locate it, you can try to use other methods to troubleshoot. Today we will introduce a memory leak tool, Visual Leak Detector (VLD for short), and describe in detail the complete process of using this tool to troubleshoot memory leaks. This article considers that many of my friends are novice developers, so I will explain it in more detail.
1. Overview of VLD tools
Visual Leak Detector is a free and open source memory leak detection tool for C/C++. Compared with other memory leak detection tools, it has the following characteristics when detecting memory leaks:
1) It can output the call stack of the memory leak point, and the specific file name and code line number will be displayed in the function call stack; 2) It can display the
complete data in the leaked memory;
3) It is not an independently running exe program, but an dll dynamic library, you need to introduce the library into the project and recompile the code;
4) Its source code is open source, released under the GNU license, and has detailed documentation and comments. It is a good choice for readers who want to learn more about heap memory management and memory leak troubleshooting mechanisms.
From the perspective of use, VLD is simple and easy to use. For users, as long as their code contains the header file of VLD, and the VLD dll library is copied to the directory of the exe main program, the program can be detected by running the program normally under debug. There is a memory leak problem. From a research perspective, the VLD source code is open source. If you delve deeper into the source code, you can learn the principles of heap memory fragmentation and release, the principles of memory checking, and common techniques for machine memory operations.
2. Download and install VLD
The latest version of VLD is 2.5.1. Go to the official page of VLD and download this version.
2.1. Download VLD
If you find Microsoft's official page about VLD ( https://marketplace.visualstudio.com/items?itemName=ArkadyShapkin.VisualLeakDetectorforVisualC ), as shown below:
Click the "Get Stated" button to enter VLD's github page:
Click the hyperlink of vld-2.5.1-setup.exe at the bottom of the page to download. The download will fail midway.
You can go to the https://kinddragon.github.io/vld/ page and click the "Download Installer" button to download, as follows:
2.2. Install VLD
First go to the website to download the installation package of the latest version of Visual Leak Detector 2.5.1, and install it directly after downloading. During the installation process, you will be asked to choose whether to add VLD to the environment variables and Visual Studio. There is no need to check it here. There is no need to automatically configure it for us. We can manually configure it in the project when we need to use VLD.
3. VLD installation directory and file description
VLD is not an independently running exe program, but a dll library. Therefore, the VLD installation package contains the .h header files, .lib and .dll library files compiled by VLD. It does not install an executable exe program. , just release these into the installation directory.
3.1. Installation directory and file description
VLD is installed in the path C:\Program Files (x86)\Visual Leak Detector by default. We can go to the installation directory to take a look, which mainly contains 3 folders:
The include folder contains the header files of the VLD library, as follows:
The vld.lib file is stored in the lib folder. There are two versions, one is vld.lib for Win32 and the other is vld.lib for Win64. Binary files such as dll are stored in the bin folder, as shown below:
There are also 32-bit and 64-bit versions.
Similar installation packages will also be used when compiling libcurl open source code. The libcurl library will call the openssl open source library interface internally, but the openssl library is not provided in the libcurl library source code. We can download the openssl installation package from the website. This installation The package contains the library files and header files of openssl, that is, the released library files and header files are in the installation directory.
3.2. Detailed description of 32-bit and 64-bit versions
When using IDE to compile Windows programs, you can compile 32-bit (corresponding to x86) or 64-bit (corresponding to x64). Only 32-bit programs can be run on a 32-bit Windows system, and 64-bit programs cannot be run. A 64-bit Windows system can run 64-bit programs or 32-bit programs (providing compatibility with 32-bit programs).
Older Windows systems may still be 32-bit, for example, some Win7 systems are still 32-bit. However, the relatively new Win10 and Win11 systems are all 64-bit systems. In order to be compatible with 32-bit Windows systems, many software directly compile the software into 32-bit programs, so that the programs can run on both 32-bit and 64-bit Windows systems.
There are also many programs that provide 32-bit installation packages and 64-bit installation packages, so users can choose the corresponding version to install according to their own needs. If it is a 32-bit Windows system, only the 32-bit installation package can be installed; if it is a 64-bit Windows system, both 32-bit and 64-bit installation packages can be installed.
From a developer's perspective, there are two points to note:
1) There is a big difference in the size of virtual memory allocated by 32-bit and 64-bit program processes in the system.
For 32-bit programs, the system will allocate 2 to the 32nd power of virtual memory to the started program, that is, 4GB. For 64-bit programs, the system will allocate 2 to the 64th power of virtual memory to the program process, that is, the virtual memory is very large, much larger than the 4GB virtual memory of 32-bit programs. For 32-bit programs, 2GB is user-mode memory and 2GB is kernel-mode memory. For large-scale software, it will occupy a large amount of memory space during operation, and there may be insufficient virtual memory. If the virtual memory is not enough, , an Out of memory memory exhaustion exception will occur. When we talked about memory leaks before, we also talked about this memory exhaustion exception.
2) Exe and dll libraries with different bit numbers cannot be mixed.
32-bit programs cannot use 64-bit dll files, and 64-bit programs cannot use 32-bit dll files. Because the number of bits is different, the addressing range is different. 32-bit programs must use 32-bit dll files, and 64-bit programs must use 64-bit dll files. Therefore, VLD provides two versions of the library, 32-bit and 64-bit. Users can choose the corresponding version according to the number of bits in their own program.
4. Introduce VLD into the project
Visual Leak Detector is not an exe executable program, which is different from tools that can be run directly. It is a dll dynamic library that needs to be integrated into our code, recompile the code, and then detect it while the program is running.
When we refer to VLD, just like referencing an ordinary dll library, we first include the library's header file (vld.h), then introduce the library's .lib file (vld.lib, needed when compiling and linking), and then add the dll Copy the file to the directory of the exe main program.
1) Include vld.h header file (for compilation)
Before including the vld.h header file, you need to set the path of the vld.h header file to the project properties: C/C++ -> General, add the path of the vld.h header file in the additional include directory, as shown below :
In this way, when compiling the code, you will go to the above path to find the vld.h header file.
2) Introduce the vld.lib file (for linking)
Before introducing the vld.lib file, you need to set the path where the vld.lib file is located in the project properties: Linker -> General, add the path where the vld.lib file is located in the additional library directory, as follows:
In this way, when compiling and linking, the vld.lib file will be found in the above path and linked. Here, we do not need to manually introduce the vld.lib file into the project code, because the vld.h header file has been automatically introduced for us, as shown below:
3) Copy the vld.dll library file to the exe main program directory (for running)
Go to the bin folder in the installation directory and copy the dll and other files to the directory of the exe main program.
Compile the code, run the program, and view the detection results.
5. Example explanation of memory leak detection
I previously created a win32 console project TestMemLeak, and then added a line of code to dynamically apply for memory in the main function, as shown below:
When the main function exits, the memory is deliberately not released to test the detection effect of VLD.
5.1. Error when starting the program
As mentioned above, set the paths of the header files and .lib files to the project, and then include the vld.h header file. Then compile the code and start debugging. As a result, an error occurs when starting, and the
following prompt box pops up:
The program cannot be started, and the corresponding exception code is 0xc0150002.
In order to understand the meaning of this error code, directly enter the familiar error code macro in VS: STATUS_STACK_OVERFLOW
and then go to the header file defined by the corresponding system exception code. The corresponding path is: C:\Program Files (x86)\ Microsoft SDKs\Windows\v7.0A\include\ntstatus.h
tried to search for the exception code 0xc0150002 in the header file, and found it as expected, as follows:
The system cannot process binding information from the application. Is it possible that when copying files in the bin directory, not only vld_x86.dll must be copied, but other files in the directory must also be copied?
So I copied dbghelp.dll and Microsoft.DTfW.DHL.manifest in the bin directory to the directory of the exe main program , and then re-run the exe program, and no more errors were reported.
5.2. Start debugging and view the memory leak report
Because the main function is relatively simple, it exits immediately after entering, and the program exits. Then in the output window of Visual Studio, I saw: Visual Leak Detector detected memory leaks!, that is, VLD detected a memory leak, as shown below:
Printed out the address and size of the memory leak:
---------- Block 1 at 0x01497020: 1024 bytes ----------
At the same time, the function call stack of the thread where the leaked code is located is also printed out, and then the contents of the memory where the memory is leaked are displayed. Double-click the line of code in the picture to jump to the line of code where the memory leak occurred:
5.3. Use of vld.ini configuration file
There is also a vld.ini configuration file in the VLD installation directory, as shown below:
Some configurations of VLD can be made in this configuration file. If you want to use this file, you need to copy it to the directory of the exe main program.
You can use the ReportTo configuration item. By default, the analysis report is output to the Debugger window, as shown below:
It can be set to both, so that it can be output to the debugger window or the detection report can be output to a file. If the ReportTo option is set to both, the ReportFile option must also be set to specify the file name to be exported to, such as:
There are other configuration options, and there are detailed annotations in the file. If you are interested, you can try them yourself.
6. Finally
You can also use the umdh program in Windbg to detect memory leaks. We have used it in our projects and the effect is good. For the detailed process of using umdh to detect memory leaks, please refer to the article I wrote before:
Using Windbg to locate memory leaks in Windows C++ programs https://blog.csdn.net/chenlycly/article/details/121295720 When using umdh analysis, no need It is more convenient to recompile the code. When using VLD, you need to recompile the code, which will be more troublesome. Especially for large-scale software, the software contains multiple dll modules. Different dll modules are maintained by different development groups. It is not easy to recompile all modules with VLD, which requires overall coordination and is not an easy task.
In addition, these memory leak detection tools are not omnipotent and cannot detect leaks in all scenarios. Because large-scale software contains multiple modules, the code is cumbersome and complicated. Some modules will apply for memory as soon as they are launched and are never released; some may use a memory pool, and memory management is more complicated. This will lead to false detection by the tool. Whether it is a real memory leak point needs to be analyzed based on the specific code and business. If one tool cannot detect it, you need to try other tools, or even many tools.
As for tools to analyze memory leaks, there was a powerful tool called BoundsChecker a few years ago, but this tool has not been maintained for a long time, and the new version of Visual Studio can no longer be used. In addition, Visual Studio 2019 V19.6 has introduced Google’s memory analysis tool AddressSanitizer:
Also try AddressSanitizer. For how to use the AddressSanitizer memory analysis tool in VS, you can read the detailed instructions in Microsoft's official article:
Using AddressSanitizer in Visual Studio https://docs.microsoft.com/zh-cn/cpp/sanitizers/asan?view=msvc-170 To use AddressSanitizer integrated in Visual Studio, you need to upgrade the IDE to Visual Studio 2019 V19. 6 or above, it takes a certain amount of time and manpower to upgrade multiple modules of a large software from top to bottom to a certain version.