Hallo zusammen,

wir sind vor einiger Zeit von Seattle auf Rio umgestiegen. Wir haben bemerkt, dass wir bei unseren Unittests (dUnit) zum Beispiel die Option "Test abbrechen, wenn Memory-Leaks gefunden wurden" nicht mehr setzen können.

Nach einigen Recherechen haben wir es nun doch hinbekommen, indem wir Einstellungen/Kompilerschalter in der Options.inc Datei vorgenommen haben. Die Einstellung von oben lässt sich jetzt wieder auswählen und aktivieren. Allerdings schlagen Tests mit Memory-Leaks trotzdem nicht mehr fehl, sondern bleiben grün. Ich kann mich erinnern, dass bei Seattle in solchen Fällen der Test fehlgeschlagen ist und eine Meldung mit der größe des Memory-Leaks angezeigt wurde.

Was jetzt zumindest wieder funktioniert, ist, Memory-Leaks über die Option "ReportMemoryLeaksOnShutdown := true" beim Schließen der Unittests anzuzeigen. Und es wird nun nach der Ausführung der Tests auch eine Datei angelegt, in die eine Liste mit Memory-Leaks inkl. Callstacks geschrieben wird. Das heißt also, dass die Memory-Leak Detektion prinzipiell funktioniert.

Weiß jemand, ob und wie man die Tests unter Delphi Rio fehlschlagen lassen kann, wenn man Memory-Leaks eingebaut hat?
Und wird FastMM4 eigentlich weiterentwickelt? Im Internet findet man Sourcen, die zum Teil schon mehrere Jahre alt sind.

Daran verzweifele ich auch immer wieder bei jeder Neuinstallation.

Ich habe grade ein Projekt vor mir bei dem es funktioniert.


In den Projektoptionen ist als "Conditional Define" "FastMM" eingetragen. $(BDS)\Source\DUnit\src ist im Projekt-Suchpfad.


FastMM4.pas natürlich auch im Suchpfad

Ich glaube es war wichtig den DCU-Ausgabepfad für das Projekt irgendwohin zu setzen damit er auch wirklich den den Quelltext nimmt und darauf "FASTMM"-Bedingung anwendet. Nicht dass er irgendwo schon fertig kompilierte DCUs findet und die einfach nimmt.

Hallo Günther,

danke für deine Antwort. Es ist schon mal gut zu hören, dass ich nicht der einzige bin, der Probleme damit hat.

Der Compiler-Schalter scheint auf jeden Fall übernommen zu werden, denn die GUI sieht bei mir ähnlich aus wie bei dir (alle Menü-Items sind auswählbar). Und ich habe in der Options.inc ja auch noch andere Optionen über die Kompiler-Schalter geändert, die ebenfalls übernommen wurden (z. B. dass die Memory-Leaks in einer Datei berichtet werden). Die Eigenschaft "Report memory leak type on shutdown" funktioniert. Aber "Fail TestCase if memory leaked" hat keine Auswirkung.

Das mit den ganzen Pfaden (Suchpfad, Bibliothekspfad, ...) ist so eine Sache. Ich habe mich bislang noch nie ausführlich damit beschäftigt und kenne noch immer nicht deren genaue Beduetung und Auswirkungen. Aber wie oben geschrieben denke ich nicht, dass die Pfade das Problem sind. Die Kompiler-Schalter werden erkannt.

Ich habe gestern mal versucht, in dUnit reinzudebuggen. Die Datei GUITestRunner.pas ist vorhanden. Möchte ich aber tiefer reingehen (z. B. in die Klasse TTestResult in TestFramework.pas), dann bekomme ich die Meldung, dass die Datei TestFramework.pas nicht gefunden wurde. Ich habe hierzu auch nur die dcu auf der Festplatte gefunden. Wird da von Delphi einfach nur die dcu mitgeliefert oder ist hier vllt. das Problem, dass mir die Quelltext-Dateien fehlen?

Das klingt als funktioniere FastMM wie gehabt, aber DUnit bekommt von der FastMM-Integration noch nichts mit.

Mit Rio habe ich noch nichts probiert. Vielleicht wurde ja wirklich was entfernt? Ab Tokyo oder Rio wurde auf einmal DUnitX statt DUnit präsentiert, nicht dass von DUnit auf einmal etwas fehlt? Ich kann mich unter Seattle nicht erinnern dass auf einmal Quellcode von DUnit fehlte...

Ich versuche im Verlauf des Tages mal meine Tokyo-VM (statt momentan Seattle) zum Laufen zu bringen und schreibe dann die Schritte mit wie man das in DUnit zum laufen bringen sollte...

Zitat:

Das klingt als funktioniere FastMM wie gehabt, aber DUnit bekommt von der FastMM-Integration noch nichts mit.

Ich habe das Problem gefunden: Es lag tatsächlich an den fehlenden .pas Dateien (TestFramework.pas und ggf. FastMMMemLeakMonitor.pas) In TestFramework.pas gibt es auch die Logik mit den Compiler-Schaltern. Dadurch, dass ich bisher nur die dcu zur Verfügung hatte, waren die Compiler-Schalter nicht aktiv. Ich habe die Quelltextdatei doch noch gefunden und an die Stelle kopiert, an der auch die GUITestRunner.pas Datei liegt.

Nochmals vielen Dank für deine Unterstützung. Ohne deine Anregungen hätte ich das Problem wahrscheinlich nicht lösen können.