Knowing where memory is being allocated using FastMM

Question

I am trying to debug memory usage in a large application using Delphi 7. I was able to installed fastmm debug full dll and with it solve some leak problems.

I also installed the memory usage tracker, allowing me to see which blocks were allocated and of what size they are.

My question is, is there a way to find out where the blocks were allocated? I know it is possible because if the memory wasn't freed a stack trace gets printed. Is there a way to 'poke' at fastmm to get it to print the stack trace for a given allocation?

Side question: if the start address of an allocation is known, is there a way to find out which class the object is? (assuming that the allocation was for a object.

Answer 1

You can either:

• try to use LogAllocatedBlocksToFile procedure. If its ALastAllocationGroupToLog param is less than AFirstAllocationGroupToLog or is zero, then all blocks along with their allocation call stacks are logged. However, if your app has many memory allocations, prepare to long waiting. I experienced about 4 hrs wait time and 1.5Gb resulting file. (Side-note: use glogg to view such large files)
• modify FastMM4.pas so implementation's LogCallStack will be visible in interface. Or you can try to use it directly from FastMM_FullDebugMode.dll

On the side question: try to use DetectClassInstance function.

Answer 2

If you use FullDebugMode and enable the conditionals that will write the data to a file, then you should get exactly what you're asking for. It will write out a stack trace for every leaked allocation when the program shuts down. (If you're debugging a program with a lot of memory leaks, this can take a while. I've seem it make shutdowns last for 10 minutes or more if the leaking item is a container that holds lots of other objects.)

Answer 3

Considering you said in a comment that the app's memory gets cleaned up nicely on app's closing for me sounds you're looking for logical memory leaks - in other words: objects that are alive more time than needed but when the time arrive for finish the app they are cleaned because exist code to clean them.

Example:

• Create an TForm using the Application as owner and the variable that references it is the global one that Delphi creates when create the form's unit.
• Config the Form's CloseAction to caHide (in the OnClose event)
• Show the form, operate on it
• Close the form and never more use it until the app closes
• Close the app, which makes Application clear all the objects it owns

So you have an logical memory leak but not an physical memory leak - which is the kind that FastMM can easily detect. Since you not intended that our hypothetical TForm live until the application finish, it semantically leaked but since it is referenced and there is code that destroys it at the end of application, to FastMM is a normal allocation.

That said appears you need not the memory dump of the memory manager, but an memory profiler.