Spring4D, Memory-Leaks, alte Version

[Stevie]

Wenn madExcept in dieser Unit Memory leaks reportet, dann liegt madExcept falsch.
Ein Blick in den class destructor, den es auch schon 2017 gab, zeigt, dass dort die internen dictionaries freigegeben und somit alle registrierten Converter freigegeben werden.

Ich mag madExcept aber dessen memory leak reporting hab ich bisher zugunsten von FastMM und LeakCheck (letztes speziell für Unittests) nicht angefasst.
Ich vermute mal, dass der Mechanismus, der die noch existierenden Allokierungen checkt, einfach zu früh läuft.

Zitat von Der schöne Günther:

(mittlerweile gibt es auch schon 1.2.6 2.0.1)

fixed

[jaenicke]

Kann man bei madExcept nicht auch bekannte Memory Leaks registrieren? Solange man weiß, dass es sich um Leaks handelt, die keiner Behandlung bedürfen, wäre das die einfachste Lösung.

[freimatz]

@jaenicke: ja kann man. Dazu muss man aber sicher das Leak angeben, also muss man an den Speicher rankommen.

Zitat von Stevie:

Wenn madExcept in dieser Unit Memory leaks reportet, dann liegt madExcept falsch.
Ein Blick in den class destructor, den es auch schon 2017 gab, zeigt, dass dort die internen dictionaries freigegeben und somit alle registrierten Converter freigegeben werden.

Ich gehe nach wie vor davon aus, dass madExcept richtig liegt.
Bei einem anderen Projekt habe ich die Info, dass (min.) ein Package beim Ende nicht entladen wird. Dann kommt auch der class destructor nicht zum Zug. Und dann hat die Suche nach Leaks so keinen Sinn.
Ob das bei dem Projekt von obigem Beispiel auch so ist, müsste ich noch prüfen.
Danke für alle Hinweise.