Speicherleaks finden unter DX Seattle

[tommy84]

Guten Morgen Praxis,

momentan beschäftige ich mich mit dem Thema Memory Leaks.
Nach Recherche bin ich auf folgende Möglichkeiten gestoßen:

1. FastMM
2. MadExcept
3. EurekaLog
4. ReportMemoryLeaksOnShutdown := True;
5. DDObjects

Zu dem Thema finden sich einige Seiten in Netz, allerdings sind diese Teils schon einige (6+) Jahre alt.

Daher frage ich mich, ob diese Programme immernoch in DX Seattle im Jahre 2016 genutzt werden sollten, oder bereits überholt sind?

Nachdem ich diese Emba-Wiki Seite gelesen habe frage ich mich, ob FastMM mittlerweile in DX Seattle integriert wurde?
Oder ist mit "vollständige Version" die FastMM Version auf SourceForge gemeint?


Welche Tools verwendet Ihr zum Auffinden von Speicherleaks?


- Tommy

[Sir Rufo]

Der integrierte FASTMM reicht mir zur Memleak-Diagnose

[tommy84]

Zitat von Sir Rufo:

Der integrierte FASTMM reicht mir zur Memleak-Diagnose

Gehe ich richtig in der Annahme, dass damit ReportMemoryLeaksOnShutdown := True; gemeint ist?

[Der schöne Günther]

Zitat von tommy84:

Nachdem ich diese Emba-Wiki Seite gelesen habe frage ich mich, ob FastMM mittlerweile in DX Seattle integriert wurde?
Oder ist mit "vollständige Version" die FastMM Version auf SourceForge gemeint?

Soweit ich das verstanden habe ist die im RAD Studio eine etwas abgespeckte Version der Sourceforge-Version. Letztere kann bei Speicherlecks dir gleich den Stack loggen wo der Speicher angefordert wurde, das ist klasse. Und genau das macht mich auch eigentlich schon wunschlos glücklich.

Und ja, ich denke genau das meint er damit.

[KHJ]

Nur zur Info, FastMM4 ist auf GitHub umgezogen https://github.com/pleriche/FastMM4

Karlheinz

[tommy84]

Danke für euren Input. Ich werde mir dann wohl mal FastMM auf Github anschauen

[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