Hallo, gibt es eine Möglichkeit erstellte Objekte zur Laufzeit zu ermitteln?

Ich habe hier das Problem, dass bei einer Aktion der verwendete Speicher der Anwendung unfassbar steigt. Es geht um mehrere Drucke, die mit Quickreport erzeugt werden in einer historisch gewachsenen Unit. Wenn ich das Programm beende, wird der Speicher wieder freigegeben. Daher kann ich das problem auch nicht mit Hilfe der Leak Detection(MadExcept) ermitteln... Es ist aber erforderlich, dass der Speicher nach dem Druck direkt wieder freigegeben wird. ich finde aber nicht, an welcher Stelle das Problem ist. Daher wäre eine Liste hilfreich, die sämtliche erzeugten Objekte zur Laufzeit anzeigt, während ich mich an einem Breakpoint befinde.

Zitat von Getox:

Hallo, gibt es eine Möglichkeit erstellte Objekte zur Laufzeit zu ermitteln?

Das ist genau der Anwendungsfall für http://ddobjects.de/dddebug

Zitat von Getox:

Hallo, gibt es eine Möglichkeit erstellte Objekte zur Laufzeit zu ermitteln?

Offiziell erstmal NEIN, da es keine Listen gibt, wo sich alle Objekte registrieren
und es ist nicht möglich mit 100%-iger Sicherheit Objekte im Speicher zu identifizieren.


Bei TForms gibt es in Screen eine Liste aller Forms, wo man auch via Parent/Owner alle Komponenten auf den Forms finden kann,
und bei einigen Klassen gibt es eigene Listen, aber global für "Alles" ... nein.

Man kann zwar den Arbeitsspeicher durchgehn und schauen ob etwas ein Objekt sein "könnte", aber man muß da mit False-Positivs leben.
> es lässt sich nur sagen "in dem Pointer ist kein Objekt" (nach Bufferoverflow, kann das auch "futsch" sein)
> aber zu 100% kann man nicht sagen "ja, es ist ein Objekt",
denn Reste eines alten/freigegebenen Objekts oder was Anderes, was zufällig der geprüften Struktur entspricht, das kann auch was Anderes oder garnichts mehr sein.


Im Delphi ist FastMM drin > ReportMemoryLeaksOnShutdown ,
aber im "großen" FastMM gibt es noch viel mehr Möglichkeiten.

FastMM, BrainMM , Deleaker, Delphi memory leak detector, ...
und zusätzlich noch Eurekalog, MadExcept, ...


PS: for var i := 0 to 1000 do TEdit.Create(Self); in einem Timer ist zwar sowas wie ein Laufzeit-Speicherleck,
aber z.B. ReportMemoryLeaksOnShutdown wird es nicht finden, da durch den Owner die vielen Edits "vorher" aufgeräumt werden, beim Beenden der Anwendung (beim Freigeben der Form).

*gelöscht*

Hallo,

Zitat:

Wenn ich das Programm beende, wird der Speicher wieder freigegeben.

Das macht Windows, aber FastMM4 zeigt dir den offenen Speicher an.

Ja, spätestens dann.

Zitat:

Wenn ich das Programm beende, wird der Speicher wieder freigegeben.

Die Frage ist halt wann das ist.

* vor der Leckprüfung (siehe das Beispiel mit dem TEdit)
* oder danach (ganz am Ende durch Windows, wo FastMM und Co. vorher noch nachsehen kann)

Aber auch mit dem Davor ist so Einiges möglich.

Zitat:

Wenn ich das Programm beende, wird der Speicher wieder freigegeben. Daher kann ich das problem auch nicht mit Hilfe der Leak Detection(MadExcept) ermitteln

Ich weiß grad nicht ob madExcept und/oder FastMM4, aber Teilweise ist es auch zur Laufzeit möglich, manuell eine Leak-Prüfung anzustoßen.
* ein Snapshot, dann eine Aktion ausführen (Drucken), und anschließend prüfen

Zitat von himitsu:

Offiziell erstmal NEIN, da es keine Listen gibt, wo sich alle Objekte registrieren
und es ist nicht möglich mit 100%-iger Sicherheit Objekte im Speicher zu identifizieren.

Wenn 99,99% reichen (mit einer Ausnahme die mir in 10 Jahren einmal begegnet ist) dann schon. Siehe oben.

Hallo,
siehe hier
https://mikejustin.wordpress.com/201...-with-fastmm4/