Spring4D, Memory-Leaks, alte Version

[freimatz]

Hallo zusammen,
ich bin gerade in einem unit test am Bearbeiten von Memory-Leaks mit Hilfe von madExcept. Dabei kommen da etliche die sehen so ähnlich aus:
55f1e7d1 Spring.Base28.bpl Spring Valueconverters.TValueConverterFactory.RegisterCon verter
Ich schaute in die unit Spring.ValueConverters rein, verstand wie vermutet nicht allzuviel an der Stelle. Was ich dann aber verstand ist oben die Zeile:
Copyright (c) 2009-2018 Spring4D Team
Nun die Frage: sehe ich es richtig, dass es keinen Sinn macht hier weiter nach Memory-Leaks zu suchen sondern erst mal auf die neueste Version upzudaten? (Was in meinem Falle ein recht hoher Aufwand wäre.)

[Der schöne Günther]

Ich hatte neulich mit Schrecken festgestellt, dass unser Hauptprojekt auch noch auf Spring4D 1.1.4 (2016) basierte und dann auf 1.2.5 geupdatet (mittlerweile gibt es auch schon 1.2.6)

und das war natürlich schon ein bisschen Arbeit, aber eigentlich weniger wild als befürchtet, wenn ich mich richtig erinnere.


PS: Inwiefern sind das denn irgendwelche (Quasi-)Singletons, die halt einmal nur existieren (bzw. bei Bedarf das erste mal erstellt werden) und dann bis zum Ende der Anwendung einfach existieren, niemand räumt sie ab, und das wird halt als "Leak" erkannt, was aber eigentlich keiner ist...

Ich würde immer mit Unit-Tests versuchen das nachzustellen, wie es hier angeblich zum Speicherleck kommt.

PPS: Spring würde ich natürlich trotzdem irgendwann updaten.

[freimatz]

Danke Günther,
der grösste Aufwand an dem Update ist Kollegen zu überzeugen es zu machen oder mich zu lassen

Für mich - und auch madExcept - sind solche (Quasi-)Singletons auch Memory Leaks. Natürlich räumt Windows die weg, aber es wäre clean wenn die Anwendung das macht. Wenn die z.B. im initialization Teil erzeugt werden, dann gehören die im finalization Teil wieder weggeräumt.

[Der schöne Günther]

Kann man sich drüber streiten, ich bin habe da die Jahre über meine Meinung auch mehrmals geändert.

Lesenswert:

Zitat:

(...)The building is being demolished. Don’t bother sweeping the floor and emptying the trash cans and erasing the whiteboards. And don’t line up at the exit to the building so everybody can move their in/out magnet to out. All you’re doing is making the demolition team wait for you to finish these pointless housecleaning tasks.(...)

https://devblogs.microsoft.com/oldne...105-00/?p=8683



Um Speicher-Lecks durch Units-Tests aufzudecken habe ich für mich bis heute keine bessere Lösung gefunden, die Tests einfach 2 mal hintereinander laufen zu lassen 😏

[freimatz]

Hallo, Danke für die Rückmeldung.
Solche Single-Memory-Leaks finde ich auch nicht so wichtig wie die anderen. Ich möchte die trotzdem weg haben
1. Damit es sauber ist. Der Vergleich mit dem Hausabriss: Zumindest hierzulande wird auch ein Haus auch erst geleert bevor es abgerissen wird und zuletzt noch Stahl und Beton getrennt
2. Dass man es sich angewöhnt Dinge aufzuräumen.
3. Es kann ja immer noch sein, dass man aus einem Singleton mit Memory-Leak ein nicht Singeton macht - und dann das Leak vergisst zu beheben.
4. Wenn man eine Liste von Memory-Leaks hat, übersieht man leicht den wichtigen Leak. Besser dann immer alle weg, dann fällt ein neues eher auf.
4. Der wichtigste Grund für mich: Bei zwei Leaks ist madExcept sehr schnell. Aber bei einem Beispiel mit 252 Leaks benötigt madExcept ca. 20 Minuten um diese zu filtern. Das ist ein Unit-Test. Bei den Leaks im Hauptprogramm will ich es gar nicht abwarten.

[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.