FastMM Memory Leaks : Lesen und verstehen von Stacktrace

[taveuni]

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.

[nuclearping]

Zitat von taveuni:

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 von taveuni:

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 von nuclearping:

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 von sahimba:

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.

[Zacherl]

Zitat von taveuni:

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

Wäre für mich aber auch die einzige Erklärung. Gibt, selbst wenn man von den direkten Varianten (VirtualAlloc, LocalAlloc, GlobalAlloc, HeapAlloc, etc.) absieht, enorm viele WinAPIs, die Speicher alloziieren können.

Bei FormatMessage mit dem FORMAT_MESSAGE_ALLOCATE_BUFFER Flag muss man am Ende beispielsweise selbst einmal LocalFree callen.

Wenn du mit Inline Hooks vertraut bist, könntest du einfach mal die genannten APIs hooken und dann jeweils auch die Rücksprungadresse vom Stack loggen. Eventuell findest du ja darüber den Übeltäter.