Dienst frisst Speicher - ist Indy schuld?

[Assertor]

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