FASTMM locating the Memory leak code location (RPM)

FASTMM locating the code location for memory leaks

Open source FASTMM, easy to use, in the first line of the project to refer to FastMM4 (note, be sure to place in the first uses), you can debug the program when the memory leak, you can also generate reports.

In later versions of Delphi2007, it is easier to use a statement only where the project begins:

Reportmemoryleaksonshutdown: = True; Yes, and there is no prompt at run time. If you want to generate a file report, you also need to have no other settings in Fastmm4,delphi to generate a file report.

You can modify the parameter switches in the Fastmm4options.inc to modify the settings for memory management.

Instructions for use are as follows:

1. Open the FastMM4 debugging function

First put FastMM4 on top of your project, for example:

FastMM4,

Main in ' Main.pas ' {mainform},

Modify the Fastmm4options.inc again to turn on full debug mode. Cases:

{$define Fulldebugmode}

You can also define compilation constants in Project: Fulldebugmode.

Also copy the Fastmm_fulldebugmode.dll to the directory where the executable program is generated after compilation.

To open the memory leak report again: Enablememoryleakreporting.  In general, it is turned on by default. This opens the full debug mode, and if a memory leak occurs, a report file is generated, and a dialog box appears when the IDE is running. Similar report file: Xxx_memorymanager_eventlog.txt

2. The report file consists of two parts and is run append each time.

The first part is the details of the leak, showing the details of each memory block that is not freed. Cases:

A memory block has been leaked. The size is:28

{A 28-byte block of memory was not freed after the program ended}

{This memory block is allocated at the time of the call stack, that is, call stack, you can clearly see the order of the calling function. If it is a system DLL, then there is a corresponding function name. }

Stack trace of when this block is allocated (return addresses):
4028E7

4030EC

406649

412365

41236E

411dd3

426b45

427236

42888C

{This memory type, if it is a string or TObject inherited object, displays the name and line number. }

The block is currently used-an object of Class:unknown

{A 256-character memory header appears as a content hint.} }

Current memory dump of the bytes starting at pointer address 107BDD8:

The second part is the summary of the content, for example:

{This small memory block leaks The report, if there is a large memory block leak, it will add a line specifically to indicate a large memory block leak.   }this application has leaked memory. The small block leaks is (excluding expected leaks registered by pointer):

{21-28 bytes of memory block leak, unknown type one}

21-28 Bytes:unknown x 1

Note:memory leak detail is logged to a text file in the same folder as this application. To disable this memory leak check, undefine "Enablememoryleakreporting".

With this report it is only known that a memory leak exists, but there is still a need to investigate further if there is no release.

The objectives of the survey are:

1. which code in which function the memory block is allocated.

This can be seen in a report that combines content and call stacks. The first 256 bytes can be analyzed, guess the allocation, the call stack directly points out the allocation function, but some address, not directly aware of the function name and code snippets. This is the time to view the binary memory image in the Delphi IDE environment, which is the view CPU function. After setting breakpoints and stopping, can View CPU, in menu View=>debug window=>cpu, shortcut key: Ctrl+alt+c,view CPU window Center is memory image, and the source code is also labeled Well, The address on the left column is the address in the call stack in the memory report, and the page turns to find the corresponding code to know where to allocate the memory.

2. Check to see if memory is being released

You can use a log or a breakpoint to debug, if there is no free memory then fill in the code, if there is no execution then check if the execution condition is correct, if the breakpoint does not work most likely because the code will never be executed (dead code). This is based on experience and debugging, and basically the IDE and memory reports can be used to prevent memory leaks well. At the same time, you need to strengthen the test case to be able to traverse all the code and most of the key functions in the test case, so that the memory leak report will be more accurate.

FASTMM will generate a memory leak report every time after the program shuts down, if there is no pop-up memory leak warning Congratulations, the memory tube is very good.

Other than that:

1). Memory management is not a GC to automatically reclaim memory, but to check for leaks.
2). Windows system memory leaks are not checked, only within the application, but there is no way to check the system leaks, can only wait for updates.
3). Check the code after the leak and check it out. Memory release, report does not do this

FASTMM locating the Memory leak code location (RPM)