Entwickler-Ecke :: Thema anzeigen - Tool zum Auffinden von Speicherfehlern gesucht!!! (D7)

winx - Mi 24.08.05 22:18
Titel: Tool zum Auffinden von Speicherfehlern gesucht!!! (D7)

Hi,

suche ein Delphi 7 Tool, das einfach zu bedienen ist und einem hilft Speicherfehler (also vergessenen objekte, free) zu finden!

Bin für jeden Tip dankbar,
winx

LigH - Mi 24.08.05 22:25

Ich hab in Google mal kurz gesucht nach

Quelltext

1:	"memory leaks" Delphi

Gefunden habe ich u.a. Verweise auf "MemCheck", ein paar Debugging-Tools [http://www.avdf.com/mar97/delf_debug.html], sowie "MemProof" als Alternative.

Amateur - Mi 24.08.05 22:29

also memtest is eher dafür da zu gucken ob dein ram fehler hat also kaputt is oder so...

wird meist verwendet wenn man viele systemabstürze hat oder das system net starten will.
trifft also auf das topic eher net zu...
besonders weil man rebooten muss um das tool zu starten und dann wird der speicher geleert..

ich hoff ma ich hab die frage richtig verstanden. also ich hab es so verstanden dass du nen tool suchst um zu gucken ob du alle kompos freigegeben hast oder noch was im speicher hängt oder?

alzaimar - Mi 24.08.05 22:43

Memproof ist ok. Probier das mal aus. Kostnix, soweit ich weiss.

SMO - Do 25.08.05 02:35

Probiere mal FastMM4 [http://sourceforge.net/projects/fastmm/] aus. Das ist derzeit der beste Speichermanager für Delphi. Hat eine gute Debugging-Unterstützung für das Finden von Speicherlecks.

winx - Do 25.08.05 13:05

Hab das ganze (FastMM4.pas= eingebunden und es compiliert auch, allerdings kommt jetzt meine Frage:

"Wie bitte sehe ich nun Speicherlücken, bei mir läuft alles wie bisher ab?"

Hab sowas auch noch nie gemacht...

danke

SMO - Do 25.08.05 15:45

Wenn alles wie bisher abläuft ist das schon mal ein gutes Zeichen. :)

FastMM4 zeigt automatisch eine Fehlermeldung, wenn das Programm beendet wird und nicht aller Speicher wieder freigegeben wurde. Das kannst du leicht testen, in dem du einfach mal ein Leck erzeugst. Lasse z.B. mal in deinem Programm einen Befehl wie TBitmap.Create; ausführen (erzeugt ein Bitmap-Objekt ohne es einer Variable oder einem Besitzer zuzuweisen).

In der Datei FastMM4Options.inc kann man jede Menge Optionen für FastMM4 in Form von Compilerdirektiven bestimmen. Es kann nützlich sein, die ersten beiden, FullDebugMode und CheckHeapForCorruption mal zu aktivieren (einfach Punkt entfernen, damit dann {$define FullDebugMode} und {$define CheckHeapForCorruption} dasteht). Im "FullDebugMode" wird eine Textdatei, die Debuginformationen über die Lecks enthält, im selben Ordner wie dein Programm erzeugt. Die Textdatei listet normalerweise nur Speicheradressen auf, aber man kann es auch detaillierter haben, steht in der FAQ:

Zitat:

Q: When a memory error pops up in "FullDebugMode" there is no debug info in the stack traces, only addresses. Why?
A: To be able to get unit/line number info you need to have the "FastMM_DebugInfo.dll" either in the same directory as the application executable or in the path. There must also be debug info available for the application - this can be in the form of a map file, a .jdbg file or embedded jcl debug info.

Map-Dateien aktiviert man in der Delphi-IDE über das Menü Projekt-->Optionen-->Linker. Für die anderen Debuginformationen braucht man wohl die JEDI [http://www.delphi-jedi.org/] Code Library. Habe ich noch nicht ausprobiert, denn mir persönlich reichen die Hinweise, die man mit Map-Dateien bekommt völlig und meistens brauche ich nicht mal die um das Leck zu identifizieren.

Ich hoffe, das hat dir etwas geholfen, ich benutze FastMM4 auch noch nicht so lange und bin keinesfalls ein Experte.

winx - Do 25.08.05 18:33

Hallo SMO,

also ich hab das alle smal so gemacht, wie du geschrieben hast, habe die beiden "defines" gesetzt, die dll in das verzeichniss der .exe kopiert und bei projekt->options->linker die map dateien (der 4.radiobutton von oben) gesetzt.
in dem logfile sehe ich jedoch immer die meldung das er die dll nicht finden konnte.
Kannst du mir irgendwie mal noch schreiben, welches mapping du aktiviert hast oder ob ich noch irgendwas anderes setzen oder nicht setzen muß

Kannst du mir mal ein logfile mit memleak hier anzeigen, damit ich weiss, ob mir die auswertung überhaupt was bringt???

DANKE FÜR DEINE HILFE!!

retnyg - Do 25.08.05 19:11

danke für den tip mit fastMM
die stringzuweisung ist damit um 300% schneller :)

SMO - Fr 26.08.05 20:28

winx hat folgendes geschrieben:

Das stimm alles so, seltsam dass die dll nicht gefunden wird. Doofe Frage, aber du hast schon die FastMM_DebugInfo.dll genommen und keine andere dll, oder?

Zitat:

Kannst du mir irgendwie mal noch schreiben, welches mapping du aktiviert hast oder ob ich noch irgendwas anderes setzen oder nicht setzen muß

Tut mir Leid, da kann ich nicht weiterhelfen. Benutze außerdem ja auch Delphi 2005.

Zitat:

Kannst du mir mal ein logfile mit memleak hier anzeigen, damit ich weiss, ob mir die auswertung überhaupt was bringt???

Klar. Ich habe kurz mal einen Button auf eine Form gesetzt und im OnClick Handler mit GetMem 100 Bytes allokiert. Wenn das Programm beendet wird, beschwert sich FastMM4 wie üblich mit einer MessageBox und der Logeintrag mit FastMM_DebugInfo.dll und Map-Datei sieht dann so aus:

Zitat:

--------------------------------2005/8/26 20:12:31--------------------------------
A memory block has been leaked. The size is: 100

Stack trace of when this block was allocated (return addresses):
4029BF [System][@GetMem]
4360CB [Controls][TWinControl.WndProc]
436204 [Controls][DoControlMsg]
4360CB [Controls][TWinControl.WndProc]
435AE7 [Controls][TWinControl.MainWndProc]
41E0AA [Classes][StdWndProc]
77D18709 [GetDC]
77D187EB [GetDC]
77D1B743 [GetParent]

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

Current memory dump of 256 bytes starting at pointer address 9B8FE0:
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 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 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 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 70 64 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

--------------------------------2005/8/26 20:12:31--------------------------------
This application has leaked memory. The small block leaks are:

85 - 100 bytes: Unknown x 1

Ob man mit der JCL und den jdbg-Dateien noch genauere Infos bekommt (in den Readme-Dateien ist ja von Zeilennummern die Rede) kann ich nicht sagen, denn das habe ich bisher nie ausprobiert (und hab's auch nicht vor).

KidPaddle - Sa 27.08.05 10:39

FastMM gefällt ausgesprochen gut. Gerade mal über ein Projekt laufen lassen und siehe da, es werden einige Leaks anngezeigt. Das Protokoll ist sehr gut, werde gleich mal die Bugs beheben.

Danke für den Tip.

Thomas

winx - Sa 27.08.05 11:19

Hi,

jetzt habe auch ich es geschafft...allerdings wird die Logger Datei locker mal 150MB groß, soviele Fehler hab ich gar nicht...ist es möglich sich nur die gröbsten (also mit dem meisten speicher)anzeigen zu lassen???

danke,
winx

retnyg - Sa 27.08.05 17:35

interessant: indy das bei D7 dabei ist scheint leaks zu haben: man setzte ein IdHttp auf eine form und mache dann z.b. ein memo1.lines.add(idhttp1.get('http://www.vol.at'));
fastMM beschwert sich dann beim schliessen über ein 28 byte leck in TCriticalSection. :gruebel:

alzaimar - Sa 27.08.05 18:48

@winx: Versuche es so:
Programm starten, beenden. Diese Speicherlecks ausmerzen.
Dann 1.Funktion aufrufen, wieder beenden, Lecks abdichten.
usw. usw. usw