Hi,
Zitat von
Luckie:
Also ich glaube mal gehört zu haben, dass die Indianer Speicherlecks hätten - bin mir aber nicht sicher.
Nein, wir geben lediglich zwei Objekte
zum Prozessende nicht automatisch frei (TIdThreadSafeInteger und TIdCriticalSection), damit falls Aufrufe vom
OS/WinSock noch laufen diese korrekt bedendet werden und die Anwendung nicht unnötig "hängenbleibt".
Das ist aber seit Jahren bekannt, Dokumentiert und abschaltbar. Iirc ursächlich ältere Win Versionen, die ja immer noch von
Indy supportet werden, auch wenn nicht mehr von MS. Selbst die üblichen
Exception-Tracker und Leak-Detektoren kommen damit klar (angepasste FastMM in Delphi, EurekaLog, madExcept).
Aber ich würde eher das Problem im Code des Threaderstellers vermuten. Eine "Sichtprüfung" und das "Gefühl" es läge an
Indy ist ja keine geeignete Methode ein Speicherleck zu finden... Also, (Remote-) Debuggen, Logs schreiben, Objekte überwachen, Testcases her und bitte auch z.B. FastMM4 im FullDebugMode und am besten mit FullDebugModeScanMemoryPoolBeforeEveryOperation := True; (oder manuell ScanMemoryPoolForCorruption, das wird sonst sehr langsam gerade bei DBs!).
AQtime oder der Win App Verifier können auch dabei helfen gerade
Handle Leaks zu finden.
Das letzte Mal, wo ich mich habe überzeugen lassen, es läge an
Indy, verbrachte ich 3 Tage mit Debugging und konnte es nicht reproduzieren. Ich sprach mit Pierre le Riche (der vom FastMM4) und am Ende das Ergebnis: Der Fragende hatte eine andere Include-Datei für FastMM irgendwo im Searchpath...
Für konkrete Bugreports bin ich immer offen, bitte Beispielprojekt her und wir legen los
Aber bitte kein pauschales
Indy Bashing
Gruß Assertor