FastMM Optionen

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