FastMM Memory Leaks : Lesen und verstehen von Stacktrace

[sahimba]

Hallo.

Zitat:

Zitat von taveuni (Beitrag 1271628)

Hallo Sahimba,
Ich hab mir Dein Tool schon angesehen.

Das freut mich. Weisst Du, wann das war - vll. war es eine ältere Version?! (Der Preis wurde zwischenzeitlich gesenkt...)
Darf ich fragen, ob es Probleme bei der Installation der Verwendung gab oder wie der erste Eindruck war?
Ich glaube, am Userinterface sollte ic schon noch bissl schrauben.

Grüße,
S.

[Dejan Vu]

Zitat:

Eigentlich ist es mir (erstmal) egal wenn beim beenden des Programms ein Objekt welches beim Start erzeugt wurde nicht freigegeben wird.

Das sollte es aber nicht. Räum doch erst einmal deinen Code so auf, das alle Objekte weitestgehend sauber freigegeben werden. Auch wenn es eigentlich überflüssig ist, aber erstens ist das sauberer und zweitens ist dann die Suche nach den Leaks viel einfacher

[nuclearping]

Zitat:

Zitat von taveuni (Beitrag 1271612)

Hallo Nuclearping,
die Meldungen erhalte ich ja (siehe Post 1). Meine Frage bezog sich auf das deuten der Meldungen. Insbesondere wenn es sich um eine "unknown class" handelt und mehrere units/funktionen aufgeführt sind.

Es ging darum:

Zitat:

Zitat von taveuni (Beitrag 1271594)

Schön wäre es aber nach einer gewissen Laufzeit zu sehen ob das 12Byte Leak XY 100 Mal aufgetreten ist - oder eben nur ein Mal. Ist so was möglich?

Damit bekommst du zwar nicht zur Laufzeit eine Meldung, aber beim Beenden müsste er dir sowas wie das hier anzeigen:

http://download.jam-software.de/tree...g_mem_leak.png

[sahimba]

Zitat:

Zitat von nuclearping (Beitrag 1271639)

Damit bekommst du zwar nicht zur Laufzeit eine Meldung, aber beim Beenden müsste er dir sowas wie das hier anzeigen

Es gibt durchaus, und das ist gar nicht so selten, Fälle, in denen der Speichebedarf stetig wächst, Objekte in irgendwelchen Listen gehalten werden, die dann, gemeinsam mit den referenzierten Objekten, erst bei Programmbeendigung freigegeben werden. Das sind dann ja keine Speicherleaks im klassischen Sinne und es wrd Dir nichts angezeigt.

[nuclearping]

Das "Übliche", also Objekte, Pointer und sogar unfinalisierte dynamische Arrays zeigt dir der ShutDown-Report aber in der Regel schon an, bzw. gibt in Form von "Unknown" Hinweise darauf.

Aber du hast prinzipiell schon recht. Mir ging es hier auch nur darum, ihm eine "einfache" Möglichkeit anzubieten, an Informationen zu kommen, die ihm vlt. helfen.

[taveuni]

Zitat:

Zitat von sahimba (Beitrag 1271647)

Es gibt durchaus, und das ist gar nicht so selten, Fälle, in denen der Speichebedarf stetig wächst, Objekte in irgendwelchen Listen gehalten werden, die dann, gemeinsam mit den referenzierten Objekten, erst bei Programmbeendigung freigegeben werden. Das sind dann ja keine Speicherleaks im klassischen Sinne und es wrd Dir nichts angezeigt.

Ich bin nun ein bisschen weiter - trotzdem bin ich nun noch verwirrter. Mit Hilfe der FastMM Dateien und Deines DDDebug konnte ich nun den Service so kompilieren dass alle Objekte welche erzeugt werden beim beenden auch wieder freigegeben werden. Somit erhalte ich beim beenden keine Meldung mehr von FastMM.Soweit so gut. Aber: Vor Ort habe ich jetzt einen Service mit Debug kompiliert und der läuft mit der FastMM DLL im FullDebugMode. Ich rufe darin auch zyklisch "LogMemoryManagerStateToFile" auf um die Anzahl Objekte und den Speicherverbrauch zu loggen. Konkret ist es so: Ich starte den Service, der Memory Report sieht so aus (den Rest des Logs habe nicht kopiert da dieser identisch ist):

Code:

FastMM State Capture:
---------------------

62075K Allocated
11139K Overhead
85% Efficiency

Usage Detail:
 69841512 bytes: Unknown x 2736
 213740 bytes: UnicodeString x 1967
 24908 bytes: TOnDemandConverter x 479
 19188 bytes: TCriticalSection x 533
 15200 bytes: TByteMap x 152

Nach vier Tagen sieht der Report so aus:

Code:

FastMM State Capture:
---------------------

62111K Allocated
16222K Overhead
79% Efficiency

Usage Detail:
 69848804 bytes: Unknown x 2773
 231868 bytes: UnicodeString x 2091
 24908 bytes: TOnDemandConverter x 479
 19188 bytes: TCriticalSection x 533
 15200 bytes: TByteMap x 152

Und wenn ich den Service beende - keine Meldung von FastMM! Also eigentlich alles super oder?
Aber im Anhang sind zwei Screenshots zum identischen Zeitpunkt wie oben. Also beim Start und vor dem beenden. Dort sieht man dass beim Start ca. 90MB private Bytes und nach vier Tagen 600MB beansprucht werden. Nach zwei Wochen sinds dann 2GB und irgendwann crasht der Service. Was hab ich (oder FastMM) übersehen?

[Der schöne Günther]

Ich habe keine Ahnung, aber könnten es vielleicht Dinge sein die von DLLs alloziiert werden?

[taveuni]

Dann könnten es höchstens Windows DLL's sein. Andererseits - wohl kaum? Hmhh.. Ich bin ratlos.

[baumina]

Nur mal so überlegt:

Delphi-Quellcode:

procedure TForm1.Timer1OnTimer(Sender: TObject);
var
  SpeicherFresser : TEdit;

begin
  Speicherfresser := TEdit.Create(self);
end;

Meiner Meinung nach frisst der kleiner Speicherfresser während der Laufzeit des Programms immer mehr Speicher auf, da immer eine neue Instanz kreiert wird. Allerdings wird beim Beenden des Programms alles freigegeben, da der Owner = self ist.

[taveuni]

Zitat:

Zitat von baumina (Beitrag 1272601)

Nur mal so überlegt:

Delphi-Quellcode:

procedure TForm1.Timer1OnTimer(Sender: TObject);
var
  SpeicherFresser : TEdit;

begin
  Speicherfresser := TEdit.Create(self);
end;

Meiner Meinung nach frisst der kleiner Speicherfresser während der Laufzeit des Programms immer mehr Speicher auf, da immer eine neue Instanz kreiert wird. Allerdings wird beim Beenden des Programms alles freigegeben, da der Owner = self ist.

Einverstanden. Aber dann müsste die Anzahl Instanzen im memory.log von FastMM doch hochgezählt werden. Und das ist eben nicht der Fall!