madExcept Leak Report vs FastMM4 Leak Log File

delphi package - automated exception handling

madExcept Leak Report vs FastMM4 Leak Log File

Postby santiago » Thu Nov 17, 2016 10:02 pm

Hello madschi,

we have been investigating memory leaks in our app.
So far we have always used FastMM4 for this. We have FastMM4 configured so that leaks are written to a log file.

Then I remembered that madExcept can also report leaks so I decided to give it a shot.
Using the madExcept Leak Report is way nicer and comfortable than using raw FastMM4 I must say :-)

To test, I added a Memory Leak to our App.
I added the leak to the method MatClipperPolygon.TClipperPolygon.Clip.

madExcept does detect the leak, which is just great!

However there is a difference in the callstack when compared to the callstack listing that I get from FastMM4.

I added the exception to Core.bpl which is used by our App.exe.

Below is an extract from the FastMM4 log file, it points to the line where the memory leak ocurred. Very useful.

Code: Select all
--------------------------------2016/11/17 16:36:36--------------------------------
A memory block has been leaked. The size is: 100

This block was allocated by thread 0x3F14, and the stack trace (return addresses) at the time was:
5005A186 [System][@GetMem]
5005F5DF [System][TObject.NewInstance]
5005FE86 [System][@ClassCreate]
5015AB3A [System][Classes.TStringList]
47F0533 [MatClipperPolygon.pas][MatClipperPolygon][MatClipperPolygon.TClipperPolygon.Clip][248]
47F0543 [MatClipperPolygon.pas][MatClipperPolygon][MatClipperPolygon.TClipperPolygon.Clip][251]
5BEE1E6 [CAMAutoTextLocator.pas][CAMAutoTextLocator][CAMAutoTextLocator.TAutoTextLocator.CropSurfaceToInkJetExtents][647]
5BEFFC0 [CAMAutoTextLocator.pas][CAMAutoTextLocator][CAMAutoTextLocator.TAutoTextLocator.LocateAutoTextOnFrameSide][1207]
5BEFB55 [CAMAutoTextLocator.pas][CAMAutoTextLocator][CAMAutoTextLocator.TAutoTextLocator.LocateAutoText][1116]
5DE2A73 [ApmMachineService.pas][ApmMachineService][ApmMachineService.TMachineService.LocateAutoTextOperationWithinPart][1015]
54467DB [BvPart.pas][BvPart][BvPart.TPart.UpdateAutoText][5139]

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

Further below is a screenshot of the madExcept Leak Report.
You will notice that the callstack is missing info from Core.bpl, which is where the memory leak ocurred.
It is picking up other bpl's along the way though.

Any idea why this happens. From what I read madExcept relies on FastMM4 for detecting memory leaks.
It would be great if the callstack retrieved by madExcept included the function where the memory leak orginated.


Posts: 49
Joined: Thu May 05, 2016 6:01 pm

Re: madExcept Leak Report vs FastMM4 Leak Log File

Postby madshi » Mon Nov 21, 2016 10:45 am

madExcept does not rely on FastMM4 for anything. madExcept's leak detection is a completely different/separate solution.

Is there an easy way for me to reproduce the problem on my PC? In my tests the callstacks usually seem to be complete.
Site Admin
Posts: 9986
Joined: Sun Mar 21, 2004 5:25 pm

Re: madExcept Leak Report vs FastMM4 Leak Log File

Postby santiago » Mon Dec 05, 2016 3:17 pm

Hello madschi,

I uploaded a very simple sample project (Source + Binaries) for you:

The groupproj contains two projects:
VCL Forms App (Main Project)
LeakTesterLib (Runtime Package).

When you run the exe you will see a form with two buttons.

Button1 leaks a TList in the VCL exe
Button2 leaks a TStringList in the LeakTesterLib (bpl).

Press each button at least once, then shut down the app. The madExcept Leak report will appear.
The report for the leak in the exe file is fine (Button 1).

However the report for the TStringList could be better (Button 2).


The TStringList was leaked in the Unit BplLeaker:

procedure ILeakAStringList;
List: TStringList;
List := TStringList.Create;

But this unit/function is not shown at all in the callstack.

Posts: 49
Joined: Thu May 05, 2016 6:01 pm

Return to madExcept

Who is online

Users browsing this forum: No registered users and 4 guests