Wie verstecken Sie erwartete Speicherverluste in FastMM?

Question

Ich habe folgende Beispielanwendung, die das Problem zeigt:

program FalseMemLeak; 

uses 
    ShareMem; 

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

ich jetzt bin mit dem borlndmm.dll Ersatz und die FastMMFullDebug.dll und ich bekomme folgenden Bericht:

--------------------------- 
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 
--------------------------- 

Wenn ich das entfernen "schlechtes" Speicherleck alles in Ordnung und kein Bericht wird angezeigt. Sobald jedoch ein unerwarteter Speicherverlust auftritt, werden auch die registrierten Lecks aufgelistet.

Ursprünglich fand ich das, als ich für diese Indy Speicherlecks und fand heraus, dass sie registriert sind, aber immer noch unter denen berichtet, die realen Speicherlecks suchen.

Wenn ich das integrierte ReportMemoryLeaksOnShutdown := True verwende, meldet es nur das Leck für TInterfacedObject.

So ist es eine Möglichkeit, die registrierten Speicherlecks, um herauszufiltern, wenn FastMM in voller Debug-Modus?

---

Um dies deutlich zu machen: Dies ist der borlndmm.dll, die mit dem FastMM Zip kommt und in dem es heißt, dass dies der Ersatz für den aus der Box ist eine und verwendet FastMM4 und lädt die FastMM_FullDebugMode.dll. Alle Aufrufe an den Speichermanager werden somit von FastMM4 übernommen. Aber irgendwie scheint es, die registrierten Lecks Ausfiltern zu ignorieren (die mit FastMM innerhalb des Ersatz borlndmm.dll registriert sind -, die gesehen werden können, wenn diese DLL debuggen). Ja, die registrierten Lecks werden nicht gemeldet, wenn FastMM4.pas verwendet wird, aber die Änderung steht nicht zur Debatte.

Answer 1

In FastMM4Options.inc gibt es folgende:

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

Das undefining von HideExpectedLeaksRegisteredByPointer ist das, was das Verhalten verursacht, die Sie beobachten. Kompilieren Sie die Ersetzung borlandmm.dll mit HideExpectedLeaksRegisteredByPointer erneut und Ihre erwarteten Lecks werden aus dem Leckbericht unterdrückt. Jedoch

, vermutlich HideExpectedLeaksRegisteredByPointer soll nicht definiert werden. Warum das so ist bin ich mir nicht sicher, aber ich kann mir nicht vorstellen, dass Pierre es durch Zufall undefiniert hat. Wie auch immer, vielleicht ist es sinnvoll, HideExpectedLeaksRegisteredByPointer zu definieren. Vielleicht möchten Sie damit experimentieren.