Hallo,
mal etwas im Nachtrag zum Thread:
Zitat von
ele:
Indy registriert die Leaks zwar für den neuen MemoryManager von Delphi, aber soweit ich weiss nicht für FastMM. Du könntest natürlich den
Indy-Source etwas frisieren, dann musst du aber bei zukünftigen Updates die Änderungen nachführen.
Das stimmt nicht,
Indy registiert die Leaks über System.RegisterExpectedMemoryLeak(). Das leitet an den jeweiligen MM um (also SysRegisterExpectedMemoryLeak bzw. FastMM4). Alles auf Korrektheit geprüft in Rücksprache mit dem Autor von FastMM seinerzeit.
Zitat von
azury:
Okay den Integer hab ich geschafft wegzubekommen aber es ist nur einmal TIdCriticalSection drin
mal gucken ob ich den auch noch raus bekomme....
Okay nun sind beide raus.
Einmal im IdThread
Delphi-Quellcode:
// This call hangs if not all threads have been properly destroyed.
// But without this, bad threads can often have worse results. Catch 22.
TIdThread.WaitAllThreadsTerminated;
FreeAndNil(GThreadCount);
Das war ausgeklammert, wie dort beschrieben.
Das kann man machen (wobei es einfacher ist FREE_ON_FINAL für das Projekt zu definieren, als im Source zu ändern) - aber nur wenn 100% sichergestellt ist, dass jeder Thread sauber beendet wird. Da leider die meisten Entwickler gerade hier Probleme haben (unwissentlich), bleibt es per default so wie bisher.
Zitat von
azury:
Und einmal im IdComponent:
Delphi-Quellcode:
destructor TIdComponent.Destroy;
begin
inherited;
// After inherited - do at last possible moment
GStackCriticalSection.Acquire;
try
Dec(GInstanceCount);
if GInstanceCount = 0
then begin
// This CS will guarantee that during the FreeAndNil nobody will try to use
// or construct GStack
FreeAndNil(GStack);
end;
finally
GStackCriticalSection.Release;
FreeAndNil(GStackCriticalSection);
end;
Da hab ich einfach das FreeAndNil(GStackCriticalSection); angefügt.
Keine Ahnung ob das okay ist was ich da mache, aber es entstehen keine Memleaks mehr.
Wenn einer gute gründe hat warum man das nicht machen sollte, immer her damit.
Grund:
Access Violations. Du gibst bei 1. Durchlauf des Destruktors die CriticalSection bereits frei. Und was ist, wenn eine 2. Instanz nun in den Destruktor durchläuft?
Die Leaks haben ihre Berechtigung. Für berechtigte Ausnahmen gibt es FREE_ON_FINAL.
Gruß,
Assertor