AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Netzwerke Delphi idThread.pas, idStack.pas Memoryleak in Delphi2009
Thema durchsuchen
Ansicht
Themen-Optionen

idThread.pas, idStack.pas Memoryleak in Delphi2009

Ein Thema von stOrM · begonnen am 9. Dez 2008 · letzter Beitrag vom 8. Apr 2010
 
Assertor

Registriert seit: 4. Feb 2006
Ort: Hamburg
1.296 Beiträge
 
Turbo C++
 
#2

Re: idThread.pas, idStack.pas Memoryleak in Delphi2009

  Alt 10. Dez 2008, 08:45
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*
Frederik
  Mit Zitat antworten Zitat
 


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:41 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz