7

I have following sample application that shows the issue:

program FalseMemLeak;

uses
  ShareMem;

var
  o: TObject;
begin
  o := TObject.Create; // "good" leak
  RegisterExpectedMemoryLeak(o);
  TInterfacedObject.Create; // bad leak
end.

I am now using the BorlndMM.dll replacement and the FastMMFullDebug.dll and I get following report:

---------------------------
FalseMemLeak.exe: Memory Leak Detected
---------------------------
This application has leaked memory. The small block leaks are:

5 - 12 bytes: TObject x 1
13 - 20 bytes: TInterfacedObject x 1

---------------------------
OK   
---------------------------

When I remove the "bad" memory leak everything is fine and no report is shown. But as soon as there is some unexpected memory leak it also lists the registered leaks.

Originally I found this when I was looking for these Indy memory leaks and found out they are registered but still reported amongst those that are real memory leaks.

When I am using the built-in ReportMemoryLeaksOnShutdown := True it only reports the leak for TInterfacedObject.

So is there a way to filter out the registered memory leaks when using FastMM in full debug mode?


To make this clear: This is the BorlndMM.dll that comes with the FastMM zip and which states that this is the replacement for the out of the box one and it uses FastMM4 and loads the FastMM_FullDebugMode.dll. All calls to the memory manager are thus handled by FastMM4. But somehow it seems to ignore filtering out the registered leaks (which are registered with FastMM inside the replacement BorlndMM.dll - that can be seen when debugging that DLL). Yes the registered leaks are not reported when using FastMM4.pas but changing that is not up for debate.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
Stefan Glienke
  • 20,860
  • 2
  • 48
  • 102
  • 3
    FastMM is not supposed to report *registered* leaks. That is the whole point of registering them. So something else is going on. I suspect `ShareMem` and `BorlndMM.dll` are the culprit. This sounds like you are likely allocating memory in one module using one copy of FastMM, but registering memory in another module using a different copy of FastMM, so the allocating module doesn't know about the registering module's list of registered leaks. – Remy Lebeau Feb 23 '15 at 17:55

1 Answers1

6

In FastMM4Options.inc there is the following:

{$ifdef borlndmmdll}
  ....
  {$undef HideExpectedLeaksRegisteredByPointer}
....

The undefining of HideExpectedLeaksRegisteredByPointer is what is causing the behaviour that you observe. Recompile the replacement borlandmm.dll with HideExpectedLeaksRegisteredByPointer defined and your expected leaks will be suppressed from the leak report.

However, presumably HideExpectedLeaksRegisteredByPointer is intended to be undefined. As to why that is so I am not sure, but I cannot imagine Pierre undefined it by accident. Anyway, perhaps it is reasonable to define HideExpectedLeaksRegisteredByPointer. You might care to experiment with that.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490