Hi,
egal wie viele Fragezeichen du schreibst, das ist "as-designed" - und zwar seit Jahren. Google oder ein Blick in den Source von IdThread.pas hätte Dir hier schon Antwort gegeben
Die Freigabe der Objekte erfolgt zur Sicherheit (!) erst mit dem tatsächlichen Ende des Prozesses durch das
OS und nicht im Finalization-Abschnitt. Hierbei "leaken" ein threadsicherer Integer und eine CriticalSection.
Zitat:
// 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;
und
Zitat:
// 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
Wenn Du hardcoded die Objekte zur Freigabe zwingen willst, rekompiliere die Indys mit IDFREEONFINAL. Aber wenn ein Thread dann nicht richtig beendet wird und die o.g. Objekte schon von Delphi finalisiert sind, kann es eine
Exception oder mehr geben.
Wende Dich sonst an den Hersteller von EurekaLog, um in Erfahrung zu bringen, wie Du dieses Pseudo-Leak unterdrücken kannst. Bei madExcept zumindest geht es, bei FastMM4 kann man es auch.
Gruß Assertor
Nachtrag: Gerade mal per Google über EurekaLog gesucht und in der
dortigen Newsgroup gelesen:
Frage:
Zitat:
I understand that this may be a
Indy problem, but this is an older Delphi7 source so I am not sure it is safe to change.
MemCheck did not report it, so it may have ignored it.
I hesitate to change this code:
Quote:
initialization
GStackCriticalSection := TCriticalSection.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
// FreeAndNil(GStackCriticalSection);
end.
Can this be ignored?
Antwort:
Zitat:
From: Administrator
Hi,
you can try to uncomment this code and just see what appends!
__________________
Best regards...
Fabio Dell'Aria.
lol. Das ist schlau vom EurekaLog-Admin *g*