Jak ukryć oczekiwane wycieki pamięci w FastMM?

Question

Mam następujący przykładowej aplikacji, który pokazuje problem:

program FalseMemLeak; 

uses 
    ShareMem; 

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

jestem teraz za pomocą wymiany BorlndMM.dll i FastMMFullDebug.dll i dostaję następujący raport:

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

Kiedy usunąć "złe" wycieki pamięci wszystko jest w porządku, a raport nie jest wyświetlany. Ale zaraz po wystąpieniu nieoczekiwanego wycieku pamięci wyszczególnione są zarejestrowane wycieki.

Początkowo znalazłem to, gdy szukałem tych wycieków pamięci Indy'ego i odkryłem, że są zarejestrowane, ale wciąż są zgłaszane wśród tych, które są prawdziwymi wyciekami pamięci.

Kiedy używam wbudowanego ReportMemoryLeaksOnShutdown := True, zgłaszany jest tylko wyciek TInterfacedObject.

Czy istnieje sposób na odfiltrowanie zarejestrowanych wycieków pamięci podczas używania FastMM w trybie pełnego debugowania?

---

Aby to jasne: To BorlndMM.dll że pochodzi z zamkiem FastMM i który twierdzi, że jest to zamiennik dla wyjęciu z pudełka jeden i używa FastMM4 i ładuje FastMM_FullDebugMode.dll. Wszystkie wywołania do menedżera pamięci są obsługiwane przez FastMM4. Ale jakoś wydaje się ignorować filtrowanie zarejestrowanych wycieków (które są rejestrowane przez FastMM wewnątrz zastępczego BorlndMM.dll - które można zobaczyć podczas debugowania tej biblioteki DLL). Tak, zarejestrowane wycieki nie są zgłaszane podczas korzystania z FastMM4.pas, ale zmiana ta nie jest przedmiotem debaty.

Answer 1

W FastMM4Options.inc jest następujący:

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

undefining z HideExpectedLeaksRegisteredByPointer jest to, co jest przyczyną problemu, który obserwować. Skompiluj zastąpiony plik borlandmm.dll z HideExpectedLeaksRegisteredByPointer zdefiniowany, a spodziewane wycieki zostaną usunięte z raportu o wycieku.

Prawdopodobnie jednak kod HideExpectedLeaksRegisteredByPointer ma być niezdefiniowany. Dlaczego tak się nie stało, nie jestem pewien, ale nie mogę sobie wyobrazić, by Pierre nie zdefiniował tego przez przypadek. W każdym razie, być może rozsądne jest zdefiniowanie HideExpectedLeaksRegisteredByPointer. Być może zechcesz z tym eksperymentować.