Indy Memory Leak TIDCriticalSection

[X-odus]

Ich habe eine Anwendung geschrieben, die TIDTCPClient benutzt. Das alleinige Einbinden der Unit IdTCPClient (und somit IdStack) führt dazu, dass FastMM4 ein Memoryleak vom Typ TIdCriticalSection feststellen muss.

IdStack sieht folgendermaßen aus:

unit IdStack;

{$I IdCompilerDefines.inc}

interface

...

implementation

var
  GInstanceCount: Integer = 0;
  GStackCriticalSection: TIdCriticalSection;

...

initialization
  GStackClass :=
   {$IFDEF LINUX}     TIdStackLinux;   {$ENDIF}
   {$IFDEF MSWINDOWS} TIdStackWindows; {$ENDIF}
   {$IFDEF DOTNET}    TIdStackDotNet;  {$ENDIF}
  GStackCriticalSection := TIdCriticalSection.Create;
finalization
  // Dont Free. If shutdown is from another Init section, it can cause GPF when stack
  // tries to access it. App will kill it off anyways, so just let it leak
  {$IFDEF IDFREEONFINAL}
  Sys.FreeAndNil(GStackCriticalSection);
  {$ENDIF}
end.

GStackCriticalSection wird nie freigegeben, weil IDFREEONFINAL nicht in IdCompilerDefines.inc definiert ist.

Es ist also scheinbar Absicht, dass das "Aufräumen" durch das Terminieren der Applikation geschehen soll!?

If shutdown is from another Init section, it can cause GPF when stack tries to access it.

Was soll das heißen: "If shutdown is from another Init section"?

GPF = General Protection Fault ?!
Wann soll da der Stack drauf zugreifen (wenn der Speicher schon freigegeben ist)?

Die MM4 Leakmeldung gegen Programmende nervt ja schon!
Eine akzeptable Lösung wäre:

RegisterExpectedMemoryLeak(GStackCriticalSection);

Das funktioniert ja aber natürlich nicht, weil GStackCriticalSection im implemetation-Teil deklariert ist.

Folgendes finde ich unzulänglich, da es nicht sicherstellt, dass auch genau dieser Speicherbereich gemeint ist:

RegisterExpectedMemoryLeak(TIdCriticalSection, 1);

Hat jemand noch eine andere Idee oder Anregung?

[Christoph Schneider]

Das ist ein bekanntes Phänomen in Indy und wird mit RegisterExpectedMemoryLeak behelfsmässig "getarnt", damit die eigenen "schlimmeren" Memoryleaks nicht übersehen werden. Dieses MemoryLeak ist darum nicht weiter schlimm, weil es sich nicht kummuliert. d.h. es wird nur einmal während Runtime ein paar Bytes verschwendet ohne Repetions-charakter.