FastMM Memory Leaks : Lesen und verstehen von Stacktrace

[Der schöne Günther]

Folgendes Projekt

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}
{$R *.res}

uses
  FastMM4,
  Unit2 in 'Unit2.pas';

begin
   ReportMemoryLeaksOnShutdown := True;
   createLeak();
end.

Delphi-Quellcode:

unit Unit2;

interface
   procedure createLeak(); forward;

implementation

procedure createLeak();
begin
   TObject.Create();
end;

end.

erzeugt folgende Ausgabe:

Code:

--------------------------------2014/9/8 13:33:46--------------------------------
A memory block has been leaked. The size is: 12

This block was allocated by thread 0x1700, and the stack trace (return addresses) at the time was:
4040D6 [System.pas][System][@GetMem$qqri][4305]
4048CB [System.pas][System][TObject.NewInstance$qqrv][15436]
404ECE [System.pas][System][@ClassCreate$qqrpvzc][16746]
404900 [System.pas][System][TObject.$bctr$qqrv][15500]
405B50 [System.pas][System][@StartExe$qqrp23System.PackageInfoTablep17System.TLibModule][21884]
41D35B [Unit2.pas][Unit2][createLeak$qqrv][10]
41F3FD 
76B3338A [BaseThreadInitThunk]
777F9F72 [Unknown function at RtlInitializeExceptionChain]
777F9F45 [Unknown function at RtlInitializeExceptionChain]

The block is currently used for an object of class: TObject

The allocation number is: 110

Current memory dump of 256 bytes starting at pointer address 7EF6F520:
10 14 40 00 00 00 00 00 31 85 50 19 78 85 42 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
.  .  @  .  .  .  .  .  1  …  P  .  x  …  B  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .

--------------------------------2014/9/8 13:33:46--------------------------------
This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

5 - 12 bytes: TObject x 1

Note: Memory leak detail is logged to a text file in the same folder as this application. To disable this memory leak check, undefine "EnableMemoryLeakReporting".

Gehe von unten die letzten dir bekannten Units durch. In diesem Fall ist es

• Unit2.pas
• Die Methode createLeak
• Zeile 10

Das wird nie freigegeben.

[taveuni]

O.K von unten ist ja schon mal ein sehr guter Hinweis. Ist es möglich die Anzahl der Leaks irgendwie herauszufinden? Eigentlich ist es mir (erstmal) egal wenn beim beenden des Programms ein Objekt welches beim Start erzeugt wurde nicht freigegeben wird. 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?

[nuclearping]

Wenn du in deiner DPR ...

Delphi-Quellcode:

program ...;

uses
  ...;

begin
  ReportMemoryLeaksOnShutdown := TRUE;

  ...
end.

... schreibst, solltest beim Beenden des Programms eine entsprechende Meldung erhalten.

[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?

[mjustin]

Zitat von taveuni:

O.K von unten ist ja schon mal ein sehr guter Hinweis. Ist es möglich die Anzahl der Leaks irgendwie herauszufinden? Eigentlich ist es mir (erstmal) egal wenn beim beenden des Programms ein Objekt welches beim Start erzeugt wurde nicht freigegeben wird. 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?

Ja, indem man den aktuellen Status des FastMM4 Speichermanagers in eine Datei schreibt und diese beobachtet.
Objekte, die leaken, erscheinen dann mit einer stetig wachsenden Anzahl in der Liste.

How do I find memory leaks at run time with FastMM4?
http://mikejustin.wordpress.com/2013...-with-fastmm4/

Strategy or tools to find “non-leak” memory usage problems in Delphi?
http://stackoverflow.com/a/17365483/80901

Step by step Anleitung:

1. add a call to LogMemoryManagerStateToFile('memory.log', '') in a place where it will be called in intervals
2. run the application
3. open the log file with an editor (which auto-refreshes when the file content changes)
4. watch the first lines of the file, they will contain the memory allocations which occupy the highest amount of memory
5. if you see a class or memory type constantly has a growing number of instances, this can be the reason of your leak

[taveuni]

Zitat von mjustin:

Ja, indem man den aktuellen Status des FastMM4 Speichermanagers in eine Datei schreibt und diese beobachtet.
Objekte, die leaken, erscheinen dann mit einer stetig wachsenden Anzahl in der Liste.

Danke! Das werd ich versuchen und mich wieder melden.