Speicherleaks finden unter DX Seattle

[sahimba]

Ich antworte einfach mal, weil ich (5) entwickelt habe: http://ddobjects.de/dddebug
Und ja: das Tool läuft auch unter Delphi Seattle und wird noch weiter entwickelt.
Der Ansatz ist ein vollkommen anderer als bei FastMM, welches Dir - am Ende eines Programmes - die Leaks anzeigt. Oftmals hilft das aber nicht weiter, weil Deine Anwendung laufend Speicher anfordert und korrekterweise zu Programmschluß auch freigibt. Was zur Laufzeit passiert, kann Dir FastMM nur eingeschränkt liefern.

[hoika]

Hallo,
der letzte und vorletzte Satz passen irgendwie nicht zusammen.
Ich will die leaks, also was gar nicht freigegeben wird.
Sicher wird es auch Programme geben,
die immer mehr Speicher anfordern und zum Schluss alles korrekt freigeben,
das muss man aber auch erst mal programmieren . . .
FastMM4 zeigt mir doch zum Schluss genau an,
was zur Laufzeit im Speicher passiert ist, leider nicht chronologisch, das ist war.


Heiko

[jaenicke]

Zitat von hoika:

der letzte und vorletzte Satz passen irgendwie nicht zusammen.
Ich will die leaks, also was gar nicht freigegeben wird

Die Leaks, die am Ende noch da sind, sind allerdings oft gar nicht so relevant. Denn Windows räumt ohnehin das meiste hinterher auf, insbesondere normal reservierten Speicherplatz.
Dies kann FastMM auch in der Regel sehr gut analysieren.

Wenn die Stacktraces von FastMM nicht aussagekräftig sind, was leider immer wieder mal passiert, oder wenn es zur Laufzeit Probleme gibt, wird es schwieriger.

Ein einfaches Beispiel:
Nehmen wir eine TCP-Komponente. Diese wird nun zwischendurch für eine Kommunikation erstellt, mit Owner, einmal verwendet und dann vergessen. Durch den Owner wird diese am Ende freigegeben, FastMM zeigt dir nichts an. Mit DDObjects siehst du das aber, weil du zur Laufzeit siehst, dass die Anzahl der Instanzen dieser Komponente ansteigt.
Vermutlich hat Stefan selbst auch noch bessere Beispiele.

[hoika]

Hallo,
hm, kein gutes Beispiel
Wenn es aufgeräumt wird, ist doch schön

Nein, im Ernst.
Ein schönes Beispiel, weil ich die Komponente in einer Schleife ja 1000mal erzeugen könnte
und FastMM4 mir keine Info gibt, dass ich sie selber nicht freigebe.

Würde bei mir allerdings nicht passieren, weil bei mir der Owner idR nil ist.


Heiko