Question

I recently discovered that Delphi has a global variable called ReportMemoryLeaksOnShutdown, when set to True will detect Memory leaks when the Application closes. I found that information from reading some comments on another related question: What is the best tool to detect memory leaks in Delphi

So from the Project Source I put ReportMemoryLeaksOnShutdown := True;

Now when my Application is closed it is picking up a lot of Memory leaks. My immediate thought is to check that created Objects are freed correctly (try..finally..free etc).

I have gone over the code and I cannot see where the leaks could be coming from, and now I need to find them, because if Memory leaks are reported when the Application is exited then that very much means there are Memory leaks at runtime, which will grow in size and is bad!

From the the link above 3rd party tools were recommended such as Eureka Log. Is there a way using just the IDE and debugger to help me find and fix the problem areas?

UPDATE

I managed to get rid of about 6 memory leaks, I discovered it was to do with MDI Childs. The childs are holding some pointer data in listboxes, and when the main Application is closing, it was not freeing the childs correctly, that is now fixed.

I am now left with these 2 errors:

I found this post http://fgaillard.com/2011/02/when-the-debugger-leaks/ which may suggest the debugger is at fault with my above error?

Answer 1

First, make sure you get the full version of FastMM. It has some additional capabilities, such as FullDebugMode, which will help you here. Rebuild your project with the FullDebugMode and ‘LogMemoryLeaksToFile’ settings defined in the compiler options, and the FullDebugMode DLL in the same folder as your EXE. This will produce a file with detailed information on your memory leaks at program shtudown, in addition to the dialog box. The most useful information here will be a partial stack trace of each allocation.

Once you have this information, you can start fixing memory leaks. There’s a bit of a trick to this: Remember that object ownership generally looks a lot like a tree: One object owns other objects, which each own other objects, and so on. So what you want to look for first is the leak type with the smallest number of leaks, since that’s likely to be the root of the tree.

For example, if the report says you’re leaking one TObjectList and 1000 TMyObject instances, it’s likely that those TMyObject instances are assigned to the list and you just forgot to free the list. Fixing that would clear the whole report, so don’t go hunting around for the individual child objects until you’ve ruled out other things.