FastMM4, Delphi6, TApplication leak?

Question

I tested FastMM4 on D6. When I debug a simple application using Forms, I got 3 lines each time for a memory leak.

Memory leaked in this application. Small block leaks (excluding the expected leaks recorded by the pointer):

13 - 20 bytes: TObjectList x 3, Unknown x 3 29 - 36 bytes: TWinHelpViewer x 1 37 - 52 bytes: THELPManager x 1

This is normal?

What thing is causing this?

Thanks: dd

Answer 1

The RTL / VCL shipped with Delphi 6 contains some memory leaks. In later versions of Delphi, using FastMM removed these memory leaks from RTL / VCL.

What you need to do is register these known and expected memory leaks with FastMM. Once you have registered leaks that FastMM will not tell them. Although these leaks are real, they are best ignored for various reasons:

• The leaked memory from these known VCL leaks is tiny and does not grow throughout the process.
• The memory is returned to the system as soon as the process is completed.
• Since the leaks are in code independent of your control, there is not a huge amount that you can make. You can fix them and use your own version of the VCL units in question, but is it worth it?

The only time these leaks can make a difference is if you had a DLL that was loaded and unloaded from the same process thousands of times throughout the life cycle of that process. I do not think this is a very realistic scenario.

If you do not register leaks, the FastMM leak report becomes practically ineffective because it displays every time. If it shows every time you learn to ignore it. This leak message is very valuable, but it is valuable if it shows leaks that you control.

In my Delphi 6 project, I have the following code in my .dpr file:

// Register expected VCL memory leaks caused by Delphi unit HelpIntfs. FastMM4.RegisterExpectedMemoryLeak(36, 2); // THelpManager x 1, THTMLHelpViewer x 1 FastMM4.RegisterExpectedMemoryLeak(20, 7); // TObjectList x 3, THelpSelector x 1, Unknown x 3 FastMM4.RegisterExpectedMemoryLeak(52); // TWinHelpViewer x 1 

I also have the following in the TForm stream from which all forms in my application come down:

 var ExpectedHelpStringMemoryLeakRegistered: Boolean; procedure TMyForm.WMHelp(var Message: TWMHelp); begin if not (biHelp in BorderIcons) and not ExpectedHelpStringMemoryLeakRegistered then begin // Register expected VCL memory leaks caused by Delphi unit HelpIntfs. FastMM4.RegisterExpectedMemoryLeak(44); // TString x 1 ExpectedHelpStringMemoryLeakRegistered := True; end; inherited; end; 

Depending on which devices are used in RTL / VCL and how you use them, you may need to register various memory leaks.

Answer 2

I would suggest that this is normal if you did not fix the sources. IIRC, when it was "memproof," its author, "Atanas Stoyanov", kept a list of errors that caused a memory leak. A leak in "classes.pas", fi, produced every VCL form application. Although the product no longer exists, you can find the list on the Automated QA website. Here is the list for D6 .