CODEWITHSUNDEEP
delphimemory-leaks
user741875
user741875

Reputation:

Fixing Memory Leaks

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:

enter image description here

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?

Upvotes: 3

Views: 8425

Answers (2)

Mason Wheeler
Mason Wheeler

Reputation: 84550

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.

Upvotes: 19

David Heffernan
David Heffernan

Reputation: 612954

The best way to do this is to get the tool to tell where where the allocation was made that led to a leak. To do this you need to download and use the full version of FastMM. The version supplied with Delphi does not have that capability.

When using the full FastMM, a report will be produced with all the gory details you need, including stack traces, to tell you what piece of code leaked.

Upvotes: 7

Related Questions