AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Leak suche mit FastMM4

Ein Thema von R2009 · begonnen am 24. Jul 2010 · letzter Beitrag vom 24. Jul 2010
Antwort Antwort
R2009

Registriert seit: 9. Mär 2009
Ort: Heidelberg
440 Beiträge
 
Delphi 2007 Professional
 
#1

Leak suche mit FastMM4

  Alt 24. Jul 2010, 15:12
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
Angehängte Dateien
Dateityp: txt LCRset3_MemoryManager_EventLog.txt (20,4 KB, 9x aufgerufen)
Rainer Unger
Mein Profil:
Studium Allgemeine Elektrotechnik TH Darmstadt
Entwicklung von Tools für die Rundsteuer und Zählertechnik.
uP's Atmel Prozessoren (ATmega16,32,88...) in C und Assembler.

Geändert von R2009 (24. Jul 2010 um 15:16 Uhr)
  Mit Zitat antworten Zitat
generic

Registriert seit: 24. Mär 2004
Ort: bei Hannover
2.395 Beiträge
 
Delphi XE5 Professional
 
#2

AW: Leak suche mit FastMM4

  Alt 24. Jul 2010, 15:20
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.
Coding BOTT - Video Tutorials rund um das Programmieren - https://www.youtube.com/channel/UCUG...aXLclwO9qA-lzA
  Mit Zitat antworten Zitat
R2009

Registriert seit: 9. Mär 2009
Ort: Heidelberg
440 Beiträge
 
Delphi 2007 Professional
 
#3

AW: Leak suche mit FastMM4

  Alt 24. Jul 2010, 15:31
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
Rainer Unger
Mein Profil:
Studium Allgemeine Elektrotechnik TH Darmstadt
Entwicklung von Tools für die Rundsteuer und Zählertechnik.
uP's Atmel Prozessoren (ATmega16,32,88...) in C und Assembler.
  Mit Zitat antworten Zitat
Benutzerbild von sx2008
sx2008

Registriert seit: 15. Feb 2008
Ort: Baden-Württemberg
2.332 Beiträge
 
Delphi 2007 Professional
 
#4

AW: Leak suche mit FastMM4

  Alt 24. Jul 2010, 15:58
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
  Mit Zitat antworten Zitat
Benutzerbild von OldGrumpy
OldGrumpy

Registriert seit: 28. Sep 2006
Ort: Sandhausen
941 Beiträge
 
Delphi 2006 Professional
 
#5

AW: Leak suche mit FastMM4

  Alt 24. Jul 2010, 16:46
Normalerweise gibts im FastMM4-Log auch einen Callstack der einem anzeigt wo das jeweilige Leck-Objekt erzeugt wurde. Ggf. mal in dem *.inc mit den Optionen schauen.
"Tja ja, das Ausrufezeichen... Der virtuelle Spoiler des 21. Jahrhunderts, der Breitreifen für die Datenautobahn, die k3wle Sonnenbrille fürs Usenet. " (Henning Richter)
  Mit Zitat antworten Zitat
R2009

Registriert seit: 9. Mär 2009
Ort: Heidelberg
440 Beiträge
 
Delphi 2007 Professional
 
#6

AW: Leak suche mit FastMM4

  Alt 24. Jul 2010, 17:40
hi,
ich jedenfalls habe keinen Callstak gefunden.
Auch nicht nach 10 Mal durchlesen des inc Files.

Grüsse
Rainer
Rainer Unger
Mein Profil:
Studium Allgemeine Elektrotechnik TH Darmstadt
Entwicklung von Tools für die Rundsteuer und Zählertechnik.
uP's Atmel Prozessoren (ATmega16,32,88...) in C und Assembler.
  Mit Zitat antworten Zitat
R2009

Registriert seit: 9. Mär 2009
Ort: Heidelberg
440 Beiträge
 
Delphi 2007 Professional
 
#7

AW: Leak suche mit FastMM4

  Alt 24. Jul 2010, 17:43
Hi oldgrumpy,
jcl und fastmm da gibts einen callstack hier offensichtlich nicht.

Grüsse
rainer
Rainer Unger
Mein Profil:
Studium Allgemeine Elektrotechnik TH Darmstadt
Entwicklung von Tools für die Rundsteuer und Zählertechnik.
uP's Atmel Prozessoren (ATmega16,32,88...) in C und Assembler.
  Mit Zitat antworten Zitat
Benutzerbild von OldGrumpy
OldGrumpy

Registriert seit: 28. Sep 2006
Ort: Sandhausen
941 Beiträge
 
Delphi 2006 Professional
 
#8

AW: Leak suche mit FastMM4

  Alt 24. Jul 2010, 18:01
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.
"Tja ja, das Ausrufezeichen... Der virtuelle Spoiler des 21. Jahrhunderts, der Breitreifen für die Datenautobahn, die k3wle Sonnenbrille fürs Usenet. " (Henning Richter)

Geändert von OldGrumpy (24. Jul 2010 um 18:02 Uhr) Grund: Tappfuhler ;)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:15 Uhr.
Powered by vBulletin® Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf