Come nascondere le perdite di memoria previste in FastMM?

Question

Ho seguente applicazione di esempio che mostra il problema:

program FalseMemLeak; 

uses 
    ShareMem; 

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

ora sto usando la sostituzione BorlndMM.dll e la FastMMFullDebug.dll e vengo seguente rapporto:

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

Quando rimuovo il perdita di memoria "cattiva" tutto va bene e nessun rapporto viene mostrato. Ma non appena si verifica una perdita di memoria imprevista, vengono elencate anche le perdite registrate.

Originariamente ho trovato questo quando stavo cercando queste perdite di memoria di Indy e ho scoperto che sono registrate ma ancora riportate tra quelle che sono vere perdite di memoria.

Quando si utilizza lo ReportMemoryLeaksOnShutdown := True integrato, viene segnalata solo la perdita per TInterfacedObject.

Quindi esiste un modo per filtrare le perdite di memoria registrate quando si utilizza FastMM in modalità di debug completo?

---

Per chiarire questo punto: Questa è la BorlndMM.dll che viene fornito con la zip FastMM e in cui si afferma che questa è la sostituzione per il fuori dalla scatola uno e utilizza FastMM4 e carica il FastMM_FullDebugMode.dll. Tutte le chiamate al gestore di memoria sono quindi gestite da FastMM4. Ma in qualche modo sembra ignorare il filtraggio delle perdite registrate (che sono registrate con FastMM all'interno del BorlndMM.dll di sostituzione - che può essere visto durante il debug di tale DLL). Sì, le perdite registrate non vengono segnalate quando si utilizza FastMM4.pas ma la modifica non è disponibile per il dibattito.

Answer 1

In FastMM4Options.inc c'è la seguente:

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

L'indefiniti di HideExpectedLeaksRegisteredByPointer è ciò che sta causando il comportamento che si osserva. Ricompilare la sostituzione borlandmm.dll con HideExpectedLeaksRegisteredByPointer definita e le perdite previste verranno eliminate dal rapporto di perdita.

Tuttavia, presumibilmente HideExpectedLeaksRegisteredByPointer non è definito. Riguardo al motivo per cui è così non sono sicuro, ma non riesco a immaginare Pierre indefinito per sbaglio. Ad ogni modo, forse è ragionevole definire HideExpectedLeaksRegisteredByPointer. Potresti provare a sperimentarlo.