Leak suche mit FastMM4

[R2009]

Hi DP'ler,
Ich arbeite mit RAD Studio 2007.
ich muss jede Menge memory leaks in einem Fremdprogramm (Quellcode habe ich) suchen.
Ich nutze Fastmm4 und das funktioniert alles ganz toll.
Ich habe das noch nie gemacht und habe Probleme mit der Deutung des log Files

Kann mir das jemand Ansatzweise erklären? Wie komme ich aus den Daten meines log Files zu den Stellen im Quelltext die den Fehler betreffen?
Das File hab ich angehängt.

Code:

A memory block has been leaked. The size is: 36

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

The allocation number is: 100612

Current memory dump of 256 bytes starting at pointer address 7F94B570:
E8 B3 4B 00 88 4C 68 01 B0 37 E7 7F 00 00 00 00 00 00 00 00 00 00 00 00 3B 31 DD 7F 80 80 80 80
80 80 80 80 80 80 80 80 00 00 00 00 91 B3 94 7F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
AA 84 01 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 4C 0D 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
4C 0D 00 00 20 00 00 00 50 AA 4E 00 52 FF E4 7F 28 BE 5F 00 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 AD 00 1B 80 80 80 80 80 00 00 00 00 C1 AE 94 7F
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2E 88 01 00 00 00 00 00 00 00 00 00 00 00 00 00
è  ³  K  .  ˆ  L  h  .  °  7  ç    .  .  .  .  .  .  .  .  .  .  .  .  ;  1  Ý    €  €  €  €
€  €  €  €  €  €  €  €  .  .  .  .  ‘  ³  ”    .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
ª  „  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  L  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
L  .  .  .     .  .  .  P  ª  N  .  R  ÿ  ä    (  ¾  _  .  €  €  €  €  €  €  €  €  €  €  €  €
€  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  *  .  .  €  €  €  €  €  .  .  .  .  Á  ®  ”  
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  ˆ  .  .  .  .  .  .  .  .  .  .  .  .  .  .

Ich habe mit diesem Teil noch nie gearbeitet und habe keine Ahnung.

Grüsse
Rainer

[generic]

Der allgemeine Literaturhinweis:
Entwickler Magazin (Ausgabe: 05.08/13.08.2008) Artikel: Speicher managen mit FastMM


Interessant ist der Block unten in der Datei:

Zitat:

This application has leaked memory. The small block leaks are:

13 - 20 bytes: TDatabase x 1, TList x 4
21 - 36 bytes: TSQLiteDatabase x 4
53 - 68 bytes: TStringList x 2

Dort steht dass du bei den Objekten jeweils die Specherfreigabe mit Free vergisst.

Also du schreibst irgendwo

sl:=TStringList.Create

und vergisst beim verlassen der Anwendung/Methode sl.Free aufzurufen.
Genau so vergisst du es vier mal bei TSQLiteDatabase und TList.
Ein TDatabase wird auch nicht freigegeben.

Die Speicherdumps sind bei Objekten weniger interessant.

[R2009]

Hi,

danke für deine Antwort. Das war mir klar. Das Teil hat aber mehr als 300000 Zeilen und ist fremd.
Das kann doch nicht sein, dass ich jedes create untersuchen muss?
Alleine Tstringlist verwendet der mehr als 100 mal

Grüsse
Rainer

[sx2008]

Natürlich suchst du erst mal nach den speziellen Klassen wie TSQLiteDatabase.Create.
Viele Speicherlecks sind auch abhängig von anderen nicht freigegebenen Objekten.
Es ist wahrscheinlich, dass wenn du die Lecks der Klasse TSQLiteDatabase geschlossen hast,
damit auch einige TStringList Lecks verschwinden werden.

Du musst auch zwischen "gefährlichen" und "ungefährlichen" Speicherlecks unterscheiden.
Gefährlich wird ein Speicherleck erst dann, wenn es im Programmablauf immer wieder auftritt.
Irgendwann hat es den ganzen Hauptspeicher aufgefressen.
Ein Leck, dass nur einmalig auftritt ist dagegen harmlos.
Gleichwohl sollte man auch einmalige Lecks schliesen, da es bei der Jagd auf gefährliche Lecks
als Störfeuer wirkt.

So findet man die gefährlichen Lecks:
1.) Programm starten und ein ein bestimmtes Formular einmal öffen und dann das Programm beenden.
Speicherlecks notieren.
2.) Genau gleich wie bei 1.) nur diesmal das Formular 10x öffnen und schliesen.
Dabei auch die Buttons, Menues, usw. ausführlich benützen.

Durch Vergleich der Speicherlecks von 1.) und 2.) findet man die gefährlichen Lecks.
Dabei sollte man sich auf die Lecks mit hoher Stückzahlen und möglichst spezifischem Klassennamen konzentrieren.
205 * TStringList ist schwer zu finden aber 10 * TOptionDialogForm lässt sich leicht entdecken.

Gute Jagd 8-)

[OldGrumpy]

Normalerweise gibts im FastMM4-Log auch einen Callstack der einem anzeigt wo das jeweilige Leck-Objekt :mrgreen: erzeugt wurde. Ggf. mal in dem *.inc mit den Optionen schauen.

[R2009]

hi,
ich jedenfalls habe keinen Callstak gefunden.
Auch nicht nach 10 Mal durchlesen des inc Files.

Grüsse
Rainer

[R2009]

Hi oldgrumpy,
jcl und fastmm da gibts einen callstack hier offensichtlich nicht.

Grüsse
rainer

[OldGrumpy]

Ich kriege im Logfile beispielsweise sowas angezeigt (exemplarisch mal für ein Leak aus den Indy-Komponenten das harmlos ist):

Code:

--------------------------------2010/7/22 16:42:25--------------------------------
A memory block has been leaked. The size is: 36

This block was allocated by thread 0x1154, and the stack trace (return addresses) at the time was:
40308A [system.pas][System][System.@GetMem][2648]
404C57 [system.pas][System][System.TObject.NewInstance][8824]
405032 [system.pas][System][System.@ClassCreate][9489]
491A9A [SyncObjs.pas][SyncObjs][SyncObjs.TCriticalSection.Create][334]
404C60 [system.pas][System][System.TObject.NewInstance][8824]
405032 [system.pas][System][System.@ClassCreate][9489]
675B2E [IdThreadSafe.pas][IdThreadSafe][IdThreadSafe.TIdThreadSafe.Create][225]
75199A [IdThread.pas][IdThread][IdThread.IdThread][606]
40592B [system.pas][System][System.InitUnits][11414]
405993 [system.pas][System][System.@StartExe][11479]
40869B [SysInit.pas][SysInit][SysInit.@InitExe][663]

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

The allocation number is: 3095

Current memory dump of 256 bytes starting at pointer address 7FEA38B0:
[...]

Natürlich braucht FastMM4 dafür Debuginfos, wahlweise als *.map, TD32 debug info, *.jdbg oder eingebettete JCL debug infos. Man kann also ganz bequem einfach externe Debuginfos für sein Projekt beim Compiler-Durchlauf generieren lassen und fertig. Im Downloadpaket von FastMM4 ist auch ein FAQ-Text der einige Tips dazu gibt.

Ich habe mir für FastMM4 zwei Sets mit Optionen für Normalbetrieb und FullDebugMode gebaut und lasse den Compiler dynamisch anhand der Compilersettings eines der beiden inkludieren. Wenn ich Optimization anknipse bekomme ich eine "Release"-Exe, wenns aus ist, bekomme ich eine "Debug"-Exe mit ausführlichem Logfile.

Wenns da im Detail irgendwo klemmt können wir gerne mal ne Troubleshooting-Session machen. :)