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
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:
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.