FastMM Optionen

[guidobrose]

Hallo

ich habe mir jetzt mal FastMM4 herunter geladen, um evtl. Speicherprobleme in meiner Anwendung finden zu können.

Ich habe die Unit auch brav nach Anleitung in die uses Klausel eingebunden und bekomme in meiner Testanwendung auch gleich einen entsprechenden Hinweis. Jetzt hätte ich natürlich gerne eine LOG Datei und eine entsprechend detailiertere Aufschlüsselung, bin aber anscheinend zu blöd dazu den FullDebugMode einzuschalten. Wie geht denn das nun?

Guido

[Nuclear-Ping]

Unter Projektoptionen -> Bedingungen

FullDebugMode;LogMemoryLeakDetailToFile

[guidobrose]

Sorry, den Menüpunkt kann ich bei mir nicht finden. Ich verwende TurboExplorer.

Ich dachte, das müsste in der FastMMOptions.inc eingestellt werden, aber ich hab keine Ahnung wie.

[bigg]

In der von dir genannten Include-Datei findest du verschiedene Compiler-Schalter, die eventuell mit einem Punkt {.$} versehen sind. Diese müßtest du entfernen und deine Anwendung neu übersetzen.


btw: Die Log Optionen heissen auch alle *Log*.

[Luckie]

Da habe ich auch gemacht, nur kann ich nirgends eine Log-Datei finden:

Delphi-Quellcode:

{Set the following option to do extensive checking of all memory blocks. All
 blocks are padded with both a header and trailer that are used to verify the
 integrity of the heap. Freed blocks are also cleared to to ensure that they
 cannot be reused after being freed. This option slows down memory operations
 dramatically and should only be used to debug an application that is
 overwriting memory or reusing freed pointers. Setting this option
 automatically enables CheckHeapForCorruption and disables ASMVersion.
 Very important: If you enable this option your application will require the
 FastMM_FullDebugMode.dll library. If this library is not available you will
 get an error on startup.}
{$define FullDebugMode}

  {Set this option to perform "raw" stack traces, i.e. check all entries on the
   stack for valid return addresses. Note that this is significantly slower
   than using the stack frame tracing method, but is usually more complete. Has
   no effect unless FullDebugMode is enabled}
  {$define RawStackTraces}

  {Set this option to check for user code that uses an interface of a freed
   object. Note that this will disable the checking of blocks modified after
   being freed (the two are not compatible). This option has no effect if
   FullDebugMode is not also enabled.}
  {.$define CatchUseOfFreedInterfaces}

  {Set this option to log all errors to a text file in the same folder as the
   application. Memory errors (with the FullDebugMode option set) will be
   appended to the log file. Has no effect if "FullDebugMode" is not set.}
  {$define LogErrorsToFile}

  {Set this option to log all memory leaks to a text file in the same folder as
   the application. Memory leak reports (with the FullDebugMode option set)
   will be appended to the log file. Has no effect if "LogErrorsToFile" and
   "FullDebugMode" are not also set. Note that usually all leaks are always
   logged, even if they are "expected" leaks registered through
   AddExpectedMemoryLeaks. Expected leaks registered by pointer may be excluded
   through the HideExpectedLeaksRegisteredByPointer option.}
  {$define LogMemoryLeakDetailToFile}

  {Deletes the error log file on startup. No effect if LogErrorsToFile is not
   also set.}
  {.$define ClearLogFileOnStartup}

  {Loads the FASTMM_FullDebugMode.dll dynamically. If the DLL cannot be found
   then stack traces will not be available. Note that this may cause problems
   due to a changed DLL unload order when sharing the memory manager. Use with
   care.}
  {.$define LoadDebugDLLDynamically}

Und wo muss die FastMM_FullDebugMode.dll hin? Meine Anwendung startet auch ohne diese DLL, obwohl die Option FullDebugMode aktiviert ist.

[Christian Seehase]

Moin Michael,

die Log-Datei solltest Du in dem Verzeichnis finden, in dem sich auch die EXE des zu prüfenden Programmes befindet.
Die DLL muss vom OS zu finden sein, wäre also im SYSTEM32 gut aufgehoben.

[Luckie]

Ich habe sie jetzt in das Verzeichnis gelegt, in dem auch die Exe erstellt wird. Aber da sehe ich nirgends eine Logdatei. Ausserdem braucht die IDE jetzt ewig lange, um das Programme zu beenden, wenn ich das Programm schliesse.

Jetzt ist eine Aufgetaucht. Kann man auch irgendwie raus bekommen in welcher Zeile im Quellcode das Speicherleck auftaucht?

[CCRDude]

Wenn die log-Datei aufgetaucht ist, enthält sie auch Callstacks. Ich nehm hier mal ein Beispiel aus einem alten Log, das ich hier noch nicht ordentlich weggesäubert hab:

Zitat:

Stack trace of when the object was allocated (return addresses):
402E7E [System][@GetMem]
403EC7 [System][TObject.NewInstance]
404172 [System][@ClassCreate]
403EFC [System][TObject.Create]
465615 [..\..\pkFileSysWin.pas][pkFileSysWin][WindowsFindFileList][136]
465B3F [..\..\pkFileSysWin.pas][pkFileSysWin][WindowsFindFileList][214]
46618F [..\pkFileSysWinTest.pas][pkFileSysWinTest][pkFileSysWinTestExecute][50]
466979 [..\pkFileSysWinTest.pas][pkFileSysWinTestDconsole][TestMain][107]

Datei, Funktion und Zeile lässt sich dort finden (von unten nach oben die Aufrufreihenfolge).
In diesem Beispiel ruft TestMain in Zeile 108 die Funktion pkFileSysWinTestExecute auf, welche in Zeile 50 WindowsFindFileList aufruft, welches in Zeile 214 WindowsFindFileList aufruft (overloaded), welches in Zeile 136 ein Objekt anlegt, das später nicht freigegeben wurde (weiter oben im Log wäre zu finden gewesen, daß es sich dabei im ein TStringList handelt).

[Luckie]

Ich bekomme leider nur so eine Ausgabe:

Code:

--------------------------------2007/7/2 15:58:57--------------------------------
A memory block has been leaked. The size is: 36

Stack trace of when this block was allocated (return addresses):
402FDE 
43189E 
432E51 
4331C7 
437656 
4388CD 
66C94A 
405113 
40517B 
407BDF 

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

The allocation number is: 238

Current memory dump of 256 bytes starting at pointer address 1032E70:
00 00 00 00 0F 00 00 00 F0 21 10 86 63 9C 80 80 00 00 00 00 FF FF FF 00 00 00 00 00 00 00 00 00
84 41 44 FC 80 80 80 80 00 00 00 00 C1 31 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FE 00 00 00 DE 2F 40 00 A1 55 40 00 CC 55 40 00 D7 04 41 00 1F AF 40 00 DE 2F 40 00 A1 55 40 00
E4 55 40 00 5E 7A 40 00 44 6A 93 7C FA 2F 40 00 ED 54 40 00 3A 85 4B 00 AB 50 40 00 5F 53 40 00
79 CC 66 00 4E E6 91 7C D7 6F 81 7C E0 6F 81 7C 00 00 00 00 24 00 00 00 00 00 00 00 B1 BF 22 F7
0C FE 68 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
80 80 80 80 4E 40 DD 08 00 00 00 00 C1 22 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
03 01 00 00 24 B0 40 00 1B 30 40 00 E9 27 42 00 50 26 42 00 5D 24 42 00 6D 59 43 00 15 5F 43 00
.  .  .  .  .  .  .  .  ð  !  .  †  c  œ  €  €  .  .  .  .  ÿ  ÿ  ÿ  .  .  .  .  .  .  .  .  .
„  A  D  ü  €  €  €  €  .  .  .  .  Á  1  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
þ  .  .  .  Þ  /  @  .  ¡  U  @  .  Ì  U  @  .  ×  .  A  .  .  ¯  @  .  Þ  /  @  .  ¡  U  @  .
ä  U  @  .  ^  z  @  .  D  j  “  |  ú  /  @  .  í  T  @  .  :  …  K  .  «  P  @  .  _  S  @  .
y  Ì  f  .  N  æ  ‘  |  ×  o  �  |  à  o  �  |  .  .  .  .  $  .  .  .  .  .  .  .  ±  ¿  "  ÷
.  þ  h  .  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €
€  €  €  €  N  @  Ý  .  .  .  .  .  Á  "  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  $  °  @  .  .  0  @  .  é  '  B  .  P  &  B  .  ]  $  B  .  m  Y  C  .  .  _  C  .

--------------------------------2007/7/2 15:58:58--------------------------------
A memory block has been leaked. The size is: 52

Stack trace of when this block was allocated (return addresses):
402FDE 
404453 
40481A 
60D63A 
7C9FB91C [SHGetDesktopFolder]
60C5A0 
60D408 
60D4A7 
60D5CE 
7E36B6A3 [OffsetRect]

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

The allocation number is: 37897

Current memory dump of 256 bytes starting at pointer address 103FB10:
40 9A 60 00 48 0F 17 00 50 16 17 00 F0 93 03 01 18 84 14 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 30 A4 01 01 D5 5C EB FE 80 80 80 80 80 80 80 80 00 00 00 00 B1 BA 03 01
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 BB 92 00 00 A1 55 40 00 CC 55 40 00 7B 56 40 00
2A 5E 40 00 CF 5D 40 00 A5 48 0F 77 8A 4B 0F 77 2A 5E 40 00 CF 5D 40 00 16 88 36 7E ED 54 40 00
4B 64 40 00 D5 63 40 00 27 45 40 00 6A 44 40 00 65 48 40 00 D4 34 45 00 E2 C7 42 00 D8 C5 42 00
55 DB 45 00 26 00 00 00 00 00 00 00 36 B1 AE 71 0C FE 68 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 80 80 80 80 80 80 C9 4E 51 8E 80 80 80 80 80 80
80 80 80 80 80 80 80 80 00 00 00 00 51 FB 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
@  š  `  .  H  .  .  .  P  .  .  .  ð  “  .  .  .  „  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  0  ¤  .  .  Õ  \  ë  þ  €  €  €  €  €  €  €  €  .  .  .  .  ±  º  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  »  ’  .  .  ¡  U  @  .  Ì  U  @  .  {  V  @  .
*  ^  @  .  Ï  ]  @  .  ¥  H  .  w  Š  K  .  w  *  ^  @  .  Ï  ]  @  .  .  ˆ  6  ~  í  T  @  .
K  d  @  .  Õ  c  @  .  '  E  @  .  j  D  @  .  e  H  @  .  Ô  4  E  .  â  Ç  B  .  Ø  Å  B  .
U  Û  E  .  &  .  .  .  .  .  .  .  6  ±  ®  q  .  þ  h  .  €  €  €  €  €  €  €  €  €  €  €  €
€  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  €  É  N  Q  Ž  €  €  €  €  €  €
€  €  €  €  €  €  €  €  .  .  .  .  Q  û  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .

--------------------------------2007/7/2 15:58:58--------------------------------
This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

1 - 4 bytes: Unknown x 6
5 - 12 bytes: Unknown x 9
13 - 20 bytes: TIEScrollBarParams x 6, TIEMouseWheelParams x 3, TIEFileBuffer x 15, TList x 63, String x 3, Unknown x 9
21 - 28 bytes: TIEVSoftShadow x 6, TPen x 15, TBrush x 30
29 - 36 bytes: TSizeConstraints x 9, TMargins x 9, TPadding x 9, TFont x 24, Unknown x 5
37 - 52 bytes: TPicture x 6, TShellFolder x 19, Unknown x 6
53 - 68 bytes: TStringList x 19, TTimer x 6, TBitmap x 27, String x 2, Unknown x 9
85 - 100 bytes: TShellChangeThread x 2, TBitmapCanvas x 3, TControlCanvas x 6
101 - 116 bytes: TBitmapImage x 27, TIEMask x 3
133 - 148 bytes: TIETransitionEffects x 3, TIELayer x 9
149 - 164 bytes: TIEBitmap x 15
261 - 292 bytes: Unknown x 3
613 - 676 bytes: TIEEdit x 3
757 - 836 bytes: TIETextControl x 3
1141 - 1252 bytes: Unknown x 3
1861 - 2052 bytes: Unknown x 5
2053 - 2260 bytes: Unknown x 3
2261 - 2484 bytes: TImageEnVect x 3

The sizes of leaked medium and large blocks are (excluding expected leaks registered by pointer): 38580, 164020, 164020, 18612, 16308, 17076, 164020, 73908, 41140, 4276

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".

[Bernhard Geyer]

Du brauchst mehr Debuginfos (z.B. TD32-Debuginfos).

[CCRDude]

Und auch wichtig: Build statt Compile, damit diese zusätzlichen Infos wirklich auch für alles erzeugt werden (weil Du da ja Lücken hast).

Ansonsten: viel Spaß beim Suchen :D
Die Übersicht sieht erstmal sehr erschreckend aus - ich denke das Log-File dürfte auch mehrere MBs haben? Aber das gute ist, das das teilweise sehr schnell schrumpft, wenn man mit den großen Dingern anfängt ;)

[Luckie]

Ähm, ja. aber was mache ich gegen Speicherlecks in Delphi-Komponenten?

[CCRDude]

Also die VCL scheint mir keine zu beinhalten, zumindest soweit ich bisher debuggt habe (meistens teste ich aber Code getrennt in Kommandozeilenanwendungen, das ist einfacher zu automatisieren und auszuwerten).
Ich benutze so gut wie keine Fremdkomponenten, daher kam das bei mir erst zweimal vor. Wenn man den Source der Komponenten hat, ist das ja auch kein Problem.

Aber ich würd erstmal mit Deinem eigenen anfangen, vieles klärt sich dann mit der Zeit. Objekte aus Klassen, die Du eigentlich gar nicht selber anlegst, sind vielleicht nur deshalb nicht freigegeben worden, weil Du ein übergeordnetes Objekt nicht freigegeben hast - manchmal löst sich da durch ein Freigeben ein ganzes Dutzend Abhängigkeiten (die dann im entsprechenden Destruktor halt plötzliche alle brav freiegegeben werden).

Und im Callstack musst Du halt die entscheidende Stelle finden - die oberen 4 Zeilen meines Beispiels etwa sind zwar aus der Unit Systen, aber der Fehler trat schon vorher auf.

[Luckie]

Nutr leider sind das meiste Speicherlecks in einer Fremdkomponente:

Code:

---------------------------
DWFotoBook.exe: Memory Leak Detected
---------------------------
This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

1 - 4 bytes: Unknown x 4
5 - 12 bytes: Unknown x 6
13 - 20 bytes: TIEScrollBarParams x 4, TIEMouseWheelParams x 2, TList x 39, TIEFileBuffer x 9, String x 2, Unknown x 6
21 - 28 bytes: TIEVSoftShadow x 4, TPen x 10, TBrush x 20
29 - 36 bytes: TPadding x 6, TMargins x 6, TSizeConstraints x 6, TFont x 16, Unknown x 5
37 - 52 bytes: TPicture x 4, TShellFolder x 19, Unknown x 4
53 - 68 bytes: TStringList x 19, TBitmap x 17, TTimer x 4, String x 2, Unknown x 7
85 - 100 bytes: TBitmapCanvas x 2, TControlCanvas x 4, TShellChangeThread x 2
101 - 116 bytes: TIEMask x 2, TBitmapImage x 17
133 - 148 bytes: TIETransitionEffects x 2, TIELayer x 5
149 - 164 bytes: TIEBitmap x 9
261 - 292 bytes: Unknown x 2
613 - 676 bytes: TIEEdit x 2
757 - 836 bytes: TIETextControl x 2
1141 - 1252 bytes: Unknown x 2
1861 - 2052 bytes: Unknown x 2
2053 - 2260 bytes: Unknown x 2
2261 - 2484 bytes: TImageEnVect x 2

The sizes of leaked medium and large blocks are (excluding expected leaks registered by pointer): 164020, 39412, 16308, 13508, 164020, 73908, 4276

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".

[CCRDude]

Hmmmm hast Du denn schon ALLE eigenen behoben?

Was ich meinte, ist etwa: eine Komponente TMyXYZBigWrapper benutzt beispielsweise 17x TBitmap, 4x TIEScrollBarParams, 9x TIEFileBuffer.

Wenn Du jetzt dein xyz vom Typ TMyXYZBigWrapper erstellst, aber nirgendwo freigibst, enthält das FastMM-Log natürlich auch die 17x TBitmap ... das würde aber "von selbst" mit weggehen, wenn Du Dein xyz.Free; nachträgst, weil dann der Destruktor von TMyXYZBigWrapper werken könnte.

Wie gesagt, es muss nicht so sein, aber es ist schon häufiger so ;)

[Luckie]

Die TIE... sind die Fremdkomponenten. Aber ich habe noch ein mögliches Speicherleck gefunden, bei dem ich noch nicht weiß, wie ich es wegbekommen soll. Aber dazu morgen mehr in einem anderen Thread, dann kann ich auch Code posten. Und dann kann man mal gucken, was noch übrigbleibt.