Angebliche Speicherlecks bei Lazy Initialization

[Der schöne Günther]

Viele Testframeworks, wie DUnit, bringen Suche nach Speicherlecks mit: Ist der Speicherverbrauch nach TearDown() größer als vor SetUp() ? Dann ist da wohl ein Leck.

Es gibt hierbei ein riesiges Problem: Lazy-Initialisierung von Klassenvariablen.
Folgendes Beispiel:

• Ich habe eine Klasse welche TEncoding.ANSI aus System.SysUtils benutzt
• Beim ersten Aufruf existiert noch keine Instanz hinter "TEncoding.ANSI" und die Klasse TEncoding erstellt eine Instanz
• Nach Abschluss des Tests habe ich ein angebliches Speicherleck, denn die Instanz hinter TEncoding.ANSI war vorher noch nicht da
• Führe ich den exakt gleichen Test ein zweites mal aus ist natürlich alles in Butter, denn die Speicherbelegung vorher und nachher ist gleich.

Ich drehe und wende mich, mir fällt keine Lösung ein. Was kann man hier tun? Alle Tests immer zwei mal ausführen?



PS: TEncoding ist ein Beispiel. Eins von sehr, sehr vielen. Sowohl im Borland RTL-Code, als auch in Libraries wie Spring4D und auch meinem ganz eigenen Quelltext. Also sagt mir nicht, das sei schlechter Stil

[BUG]

Das sieht nach Lösungsansätzen aus. Ich würde es sinnvoll finden, die Leak-Detection nur für SetUp/TearDown abzuschalten und die Singletones schon in SetUp zu Initialisieren.

[Union]

Für den Einzelfall TEncoding muß man TEncoding.FreeEncodings aufrufen. Der Klassendestruktor wird ja erst nach der finalization ausgeführt, der Klassenkonstruktor vor der initialization. OT: Welchen Musikstil machen denn die Singletones

[Stevie]

Zufall, dass das gerade heute hier auftaucht?

Wenn ja, dann schau mal hier.

Zitat von Union:

Welchen Musikstil machen denn die Singletones

Guter Name für ne Softwareentwickler Band

[BUG]

Zitat von Union:

OT: Welchen Musikstil machen denn die Singletones

Sollte es überhaupt eine Mehrzahl von Singleton geben

[Der schöne Günther]

Zitat von Stevie:

schau mal hier

Jaaa! Das sieht sehr gut aus

Zitat:

So you can detect leaks between snapshot and last allocation. This is what DUnit integration does. In test results, you'll be able to see detailed leak information including class names, reference count, string and memory dumps.

Genau das ist bislang bei mir das Problem: Die Sache mit TEncoding, oder einem TEqualityComparer in den Spring-Collections findet man nur durch Wühlen, Wühlen, Wühlen. Wenn er mir direkt sagen könnte was und wo- Perfekt.


Ich habe zwar noch keine Ahnung was TestInsight ist, was "Delphi LeakCheck" genau macht, ob es mir was bringen würde von DUnit auf DUnitX zu wechseln-- Aber das Wochenende hat ja noch nicht einmal angefangen