Angebliche Speicherlecks bei Lazy Initialization

[Der schöne Günther]

Viele Testframeworks, wie DUnit, bringen Suche nach Speicherlecks mit: Ist der Speicherverbrauch nach

Delphi-Quellcode:

TearDown()

größer als vor

Delphi-Quellcode:

SetUp()

? Dann ist da wohl ein Leck.

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

• Ich habe eine Klasse welche
  Delphi-Quellcode:

  TEncoding.ANSI

  aus
  Delphi-Quellcode:

  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
  Delphi-Quellcode:

  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? :stupid:



PS:

Delphi-Quellcode:

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

Delphi-Quellcode:

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:

Zitat von Union (Beitrag 1308231)

Welchen Musikstil machen denn die Singletones ;)

Guter Name für ne Softwareentwickler Band :stupid:

[BUG]

Zitat:

Zitat von Union (Beitrag 1308231)

OT: Welchen Musikstil machen denn die Singletones ;)

:oops:

Sollte es überhaupt eine Mehrzahl von Singleton geben :mrgreen:

[Der schöne Günther]

Zitat:

Zitat von Stevie (Beitrag 1308234)

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 8-)