FastMM4, Delphi6, Leak of TApplication?

2019-06-28 06:49发布

问题:

I checked the FastMM4 with D6. When I debug a simple application with uses "Forms", I everytime got 3 lines for memory leak.

This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

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

Is this normal?

Which thing causes this?

Thanks: dd

回答1:

The RTL/VCL that ships with Delphi 6 contains some memory leaks. In later releases of Delphi the use of FastMM led to these memory leaks being removed from the RTL/VCL.

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

  • The leaked memory from these known VCL leaks is tiny and doesn't grow during the lifetime of the process.
  • The memory returned to the system as soon as the process terminates anyway.
  • Since the leaks are in code beyond your control, there's not a huge amount you can do. You could fix them and use your own version of the VCL units in question, but is it worth it?

The only time these leaks could matter is if you had a DLL which was loaded and unloaded from the same process thousands of times during the lifetime of that process. I don't believe this is a very realistic scenario.

If you don't register the leaks then the FastMM leak reporting becomes largely ineffective because it shows every time. If it shows every time you learn to ignore it. This leak reporting is very valuable, but it is only valuable if it shows leaks that you have some control over.

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 a TForm descendant from which all forms in my app descend:

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 exactly which units you use in the RTL/VCL and how you use them, you may need to register different memory leaks.



回答2:

I would guess it is normal unless you patched the sources. IIRC, when there was 'memproof', its author 'Atanas Stoyanov' kept a list of bugs that caused memory leaks. The leak in the 'classes.pas', f.i., effected every VCL forms application. Though the product does not exist anymore, you can find the list at 'Automated QA's site. Here's the list for D6.