idThread.pas, idStack.pas Memoryleak in Delphi2009

[stOrM]

Hallo,
wollte nur mal kurz wissen ob das normal ist, dass die beiden besagten Units unter D2009 Architect nen Memoryleak auslösen?
Zeigt mir zumindest das Eurekalog an...

Ein Blick in beide Units ergibt ein {$IFDEF REGISTER_EXPECTED_MEMORY_LEAK} ????????????????????
Öhm nicht nur das es sehr nervig ist, aber kann man das ganze vielleicht sauber umgehen?

Gruß
s!

[Assertor]

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*

[stOrM]

Hehe Danke für die Antworten, was noch im Eutekalog Forum zu finden war ist, dass die Funtkion um Leaks geziehlt zu ignoerieren erst ab Version 7 zur Verfügung stehen soll!

Gruß
s!

[jbg]

Zitat von Assertor:

egal wie viele Fragezeichen du schreibst, das ist "as-designed" - und zwar seit Jahren.

Dabei ist es doch so einfach kein Speicherleck zu erzeugen, wenn man statt der Klasse TCriticalSection einfach eine globale Variable vom Typ TRTLCriticalSection nutzt. Ich glaube ich muss meinen Schreibzugriff auf das Indy-Repository wieder reaktivieren.

[Assertor]

Zitat von jbg:

Dabei ist es doch so einfach kein Speicherleck zu erzeugen, wenn man statt der Klasse TCriticalSection einfach eine globale Variable vom Typ TRTLCriticalSection nutzt. Ich glaube ich muss meinen Schreibzugriff auf das Indy-Repository wieder reaktivieren.

Naja, das war ja auch nur vereinfacht...

Sollte gehen, wenn man die TIdCriticalSection = class(TCriticalSection) mit der RTLCriticalSection ersetzt und einen Wrapper für .Enter und .Leave schreibt - sonst muß Du zu viele CodeStellen anpassen.

Aber gerne, wobei das SVN jetzt bei Atozed liegt. Unter Umständen kannst Du den Schreibzugriff nicht reaktivieren, je nach Credentials. Meld Dich doch mal in der Core Team Mailing List - da bist Du bestimmt noch drin, richtig?

Auf die Diskussion mit Remy LeBeau wegen des Expected Memory Leaks wär ich gespannt...

Gruß Assertor

[jbg]

Zitat von Assertor:

Sollte gehen, wenn man die TIdCriticalSection = class(TCriticalSection) mit der RTLCriticalSection ersetzt und einen Wrapper für .Enter und .Leave schreibt - sonst muß Du zu viele CodeStellen anpassen.

Das geht noch ganz anders. Man muss nur TIdCriticalSection.NewInstance überschreiben und dort ein gobales Byte-Array als Adresse zurückliefern. Und schon liegt die ganze Soße im "Datensegment" statt auf dem Heap.

[jbg]

Ich habe mir das jetzt nochmal genauer angeschaut. Und ich muss sagen, mir diesem Sch**ß Delphi.NET/C# Port Indy 10 sowas von umständlich und chaotisch geworden ist, dass ich nun überlege, mir eine Alternative zu suchen. Sorry, aber den Schrott tue ich mir nicht mehr an.

TIdThreadSafeInteger ist ja wohl der Abschuss. Ein InterlockIncrement/Decrement hätte es auch getan. Da braucht man kein Objekt, dass ein TCriticalSection Objekt erstellt um dann das Increment/Decrement ausführen zu können. Nein Danke.

[Assertor]

Hi Andreas,

fraglich, ob das alles wirklich in diesen Thread gehört... Du bist wohl gerade über die hohe Abstraktionsschicht und die Plattformkompatibilität gestolpert

Wer den TIdThreadSafeInteger so gebaut hat, weiß ich nicht, da ich erst seit diesem Jahr dabei bin. Grundsätzlich wird aber lieber eine Sicherheit zu viel als zu wenig eingebaut - eben im Hinblick auf die verschiedenen Platformen.

Gruß Assertor

P.S.: Reg Dich nicht auf, guck mal lieber hier rüber, um mir bei der Suche nach einem Handle Leak zu helfen

[Assertor]

Hallo,

Nachtrag hierzu:

Zitat von jbg:

TIdThreadSafeInteger ist ja wohl der Abschuss. Ein InterlockIncrement/Decrement hätte es auch getan. Da braucht man kein Objekt, dass ein TCriticalSection Objekt erstellt um dann das Increment/Decrement ausführen zu können. Nein Danke.

Nicht bei Mac OSX. Das Äquivalent von InterlockedIncrement/Decrement (OSIncrement/DecrementAtomic) liefert hier das PreIncrement, nicht das PostIncrement wie bei Windows. Ebenfalls kann es auf anderen Plattformen Probleme mit dem Alignment geben. Da war TIdThreadSafeInteger als Lösung für alle Platform die naheliegenste Wahl...

Sobald das für alle Plattformen gelöst ist, kann man darüber diskutieren. Für Win wäre natürlich ein InterlockedIncrement/Decrement besser, aber wenn Indy eins nicht braucht, dann noch mehr IFDEFs!

Zitat von jbg:

Ich habe mir das jetzt nochmal genauer angeschaut. Und ich muss sagen, mir diesem Sch**ß Delphi.NET/C# Port Indy 10 sowas von umständlich und chaotisch geworden ist, dass ich nun überlege, mir eine Alternative zu suchen. Sorry, aber den Schrott tue ich mir nicht mehr an.

Der C#/Net Code wird in Indy 11 rausfliegen, dann wird es wieder übersichtlicher.

[OT]Und grundsätzlich: Bei Euch im Team JEDI sieht es nicht viel besser aus Also aufpassen mit dem Glashaus und den Steinen

Wenn man versucht eine Komponente zu "De-JEDI-fizieren", also wieder standalone zu machen, stehen einem die Haare zu berge... Nachdem ich ewig lange auf dem JEDI Mantis versucht hatte, die Fehler der JvLinkLabel im Anti-Aliasing klarzumachen (mit Text, Demo, Bilder) kam ein Fix, der halbherzig ist - obwohl ich selbst einen bereitgestellt hatte. Auf die Mails dazu in der alten Newsgroup (talkto) wurde garnicht geantwortet. Inzwischen hab ich die Komponente geforkt und so wie David Polberger es beschrieb, den Tag Arbeit für den Fix investiert.

Lange rede, kurzer Sinn: In Sachen Installation, Demos, Doku, Webseite & Code nehmen sich beide OpenSource Projekte nicht viel. Zu komplex, zu wenig Helfer. Da sitzen wir beide im selben Boot.
[/OT]

Gruß,
Assertor