I want to thank you so much for a great posting. I have been looking for such information. Currently, memory leak is killing me at my customer sites. I am basically bleeding trying to find the leaks. Our software supposed to run 24/7/365, but little over 3 to 4 months, computer system comes to a crawl and freezes completely which requires system reboot. There were times our customers would call back saying their computer is completely destroyed that they can’t even boot to their windows operating system.

I am currently testing out FastMM494 but none of my changes to Fast4Options.inc file doesn’t seem to do anything. Am I doing anything wrong?

1. You are using dynamical unload of DLLs (if you unload a DLL – it will be impossible to read its debug information).
2. You are using shared memory manager (if you have 2 standalone memory managers for exe and DLL, then when you unload DLL, its memory manager will detect a leak. But it is not a error to unload DLL with still allocated memory with shared MM).

Break any of the above conditions and you should got nice call stacks again.

1. When you allocate memory, FastMM creates call stack, which is array of addresses.
2. Memory leak can be detected as leak ONLY at exit.
3. DLL, where memory was allocated, may be unloaded at the time of application exit.

Put these points together and you’ll see why there is no textual description: it is impossible to get one, as DLL (and it’s debug information) is no longer available, when FastMM creates log file!

I’m not aware of any way of changing it.
May be, you should post this as suggestion to Pierre le Riche?

I am using FastMM4 on a Delphi 7 application using RemObjects/DataAbstract sdk. The server application is composed of a main project and a set of DLLs where the services are implemented.

I followed all the configurations instructions to get the complete stack trace. Nevertheless, I have no detailed trace from leaks on DLL code.

To make it simple and better understand the problem, I’m using the demo project “Dynamically Loaded DLL” that comes with FastMM494 download.

First, I set the project compile/link config to get Map files, debug info and so on (for both main/dll project). I also set ReportMemoryLeaksOnShutdown := True on TestApplication.

Build all > Run… and the memory leak shows the following:

****************
——————————–2009/9/30 17:12:35——————————–
A memory block has been leaked. The size is: 4

This block was allocated by thread 0×7A8, and the stack trace (return addresses) at the time was:
1422963
1423383
14236F2
14233B8
1481E5B
1481E2C
1474F60
1452738
145289F
1474D32
7E382C75 [Unknown function at DrawFrame]

The block is currently used for an object of class: Unknown

The allocation number is: 900

——————————–2009/9/30 17:12:35——————————–
This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

1 – 4 bytes: Unknown x 1

**************

So I added a leak (TObject.Create) to the main application- TfAppMain.Button1Click.

Build All > Run… and now I got the complete stack trace for the main program leak (including line number), but nothing for the DLL leak, as following:

*****************
——————————–2009/9/30 17:20:16——————————–
A memory block has been leaked. The size is: 4

This block was allocated by thread 0×640, and the stack trace (return addresses) at the time was:
402963 [system.pas][System][@GetMem][2447]
4033A7 [system.pas][System][TObject.NewInstance][8368]
40372E [system.pas][System][@ClassCreate][9027]
4033DC [system.pas][System][TObject.Create][8383]
7E382909 [Unknown function at OpenDesktopA]
4671F8 [ApplicationForm.pas][ApplicationForm][TfAppMain.Button1Click][32]
440930 [Controls.pas][Controls][TControl.Click][4705]
437650 [StdCtrls.pas][StdCtrls][TButton.Click][3472]
4377B7 [StdCtrls.pas][StdCtrls][TButton.CNCommand][3524]
440702 [Controls.pas][Controls][TControl.WndProc][4645]
7E382C75 [Unknown function at DrawFrame]

The block is currently used for an object of class: TObject

The allocation number is: 440

——————————–2009/9/30 17:20:16——————————–
A memory block has been leaked. The size is: 4

This block was allocated by thread 0×640, and the stack trace (return addresses) at the time was:
1422963
1423383
14236F2
14233B8
1481E5B
1481E2C
1474F60
1452738
145289F
1474D32
7E382C75 [Unknown function at DrawFrame]

The block is currently used for an object of class: Unknown

The allocation number is: 901

——————————–2009/9/30 17:20:16——————————–
This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

1 – 4 bytes: TObject x 1, Unknown x 1

*****************

Is there any problem on get FastMM4 stack traces for DLLs code?
Or is there any other configuration that should be done for that?

Sorry for the long message. I really appreciate any help on that issue.

Thanks in advance.

Прежде чем приступить к продолжению описания других способов ловли “плохих” указателей, я хотел бы поговорить об утечках памяти и о меха…

Congrulations!