Leak suche mit FastMM4

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