Memproof tutorial for Delphi Memory Leak search tool

Introduction to memproof

Memproof (memory scavenger) is a very good Free debugging tool produced by automatedqa to detect memory leaks and resource leaks, it is suitable for applications developed using Delphi/C ++ builder on the Win32 platform.
Loading data ...... You can use it to conveniently find out some pointers and resources that you forgot to release. It runs the target program in debugging mode and monitors Program Creation and release operations to detect resource leakage. During the monitoring process, it will count the resources based on the resource type. After each creation, it will increase the count, and the release will decrease the count. Finally, the program will judge the resource leakage Based on the count.

The original author of memproof is Atanas Stoyanov, and later joined the automatedqa company. He is currently the main developer of the well-known aqtime software. Memproof has not been updated for a long time, the author on the official website of automatedqa also recommended that you use aqtime (http://www.automatedqa.com/products/aqtime/memproofusers.asp), because aqtime contains all the features of memproof, it also has many features not available in memproof, such as better com support, help with msdn, and platform testing. Although there are so many benefits, aqtime, after all, is a paid commercial software, expensive and relatively large. For me, I prefer memproof. The lightweight volume, simple operation, or free of charge (this is the most critical ~~). Of course, aqtime is also a good choice for large enterprise users.

Usage
L download

The latest version on the official website is (build 0.950 July 19,200 4)

1: http://www.automatedqa.com/products/memproof/index.asp
2: http://www.delphifans.com/SoftView/SoftView_1947.html

L Installation

Memproofis a green software. After the download is complete, run memproof.exe.

L preparation

Memproof requires that the target program contain complete debugging information. Open project-Options)

1. compiler panel

L remove the optimization (code optimization) Option

L select stack frames (Force Generation of call stack for all process functions)

L select debug information (generate debugging information in the DCU file)

L select use DEBUG dcus (The vcl dcu file with debugging information is linked during compilation ).



2. linker panel

L select detailed (generate a complete map file, including the module, unit, process, and other address information)

L select include td32 debug info (generate debugging information to an executable file)


This option will increase the size of the executable file, but will not affect the running efficiency and memory usage. We recommend that you do not include this option in the official release.




L start

Everything is ready. Now you can start debugging.

The following is a test program for debugging:

Create a blank project and add the following code to the oncreate event:

Procedure tform1.formcreate (Sender: tobject );

Begin

Tfont. Create; // create a tfont object, but do not release

Closehandle (0); // close a non-existing handle

End;

Set the project options according to the above introduction. Open memproof:



Resources-resource types, including error, pointers (pointer), memory (memory), GDI (canvas resource), user (System Object), and kernel (core object) registry ).

Resources count-number of resources. Current # indicates the current number, and peak # indicates the peak number.

Resources size-resource size, current # indicates the current size, peak # indicates the peak size

 

Select File-open to open the execution file to be debugged, select run-run to start running, and exit the target program normally. If memproof causes resource leakage, the resources details panel is automatically opened:




Memproof lists five memory leaks. We can see that each memory leak has a detailed call stack and the corresponding source code location.

Sometimes it will prompt that we cannot find the corresponding source code, which is the reason why no source code search path is specified. Memproof has two locations for you to set the source code search path, one for configure-search directories and the other for projects-search directories. The former sets the global path, and the latter sets the current path. It is generally recommended to set the VCL of Delphi and the path of the shared library code in the former, and set the path of the source code of the project. Memproof also provides users with the "get default for" button to quickly search the VCL source code path, you can use this button to quickly obtain the libray path of Delphi (some users install VC to overwrite the default debugging tool options, so it is possible to obtain the libray path of VC, in this case, you can copy the file directly in libray path of Delphi ).

In addition, memproof can also record the last test results to facilitate user comparison and filter functions.

To test the dynamic Connection Library, select project-parameters and select the main program in host applications. If you need to include a command line, enter the command line in parameters, then you can start the test, which is the same as the debugging method in Delphi.

Memproof does not support attach process debugging, which is a disadvantage.

 

It is actually very simple to use. I will understand it at a Glance. The following describes some experience and skills in debugging.

Tips
L progressive testing to solve the most easily discovered errors

A large software may have many leaks or errors. At this time, it can be tested progressively. The first test can be run directly and then exit immediately to check whether there is any leakage during the loading process, and then correct them one by one. Test the function modules. For example, you can only perform operations on a specific function, and then exit to check whether the module has been leaked. If yes, make corrections. Then perform the overall test. In this way, you can avoid repeated tests due to some association errors, save test time, and make the tests more targeted.

L sub-module testing, starting from a single module

As with the previous principle, to narrow down the test surface. In Moudle configers of projects, select the testing module, start to select only one module for targeted testing at a time, and then select all modules for testing.

Note: Do not select system modules such as ole32.dll and kernel32.dll.

 

L priority is given to errors. When errors and leaks coexist, priority is given to errors.

Errors are often caused by incorrect use of system APIs, such as releasing nonexistent handles, resources with insufficient access permissions, and passing incorrect call parameters. These errors often lead to code failure as expected, triggering some memory leaks. Therefore, these locations must be corrected first.

L priority should be given to system resources, and priority should be given to leakage in such cases as GDI, user, kernel, and registry.

System resource leakage is often caused by the fact that forms, canvases, and other resources are not released in time. These errors are very obvious and often contain many pointers and memory leaks. Therefore, priority is given to correction.