用完整的調試信息編譯您的應用程序,然後在鏈接器選項中,確保您的調試信息位於.EXE和/或.MAP文件中。
然後使用FullDebugMode運行FastMM,並複製/粘貼生成的.TXT文件到您的問題中。
另請參閱this post瞭解更多提示。
編輯:
一個很好的第一步是做這樣的事情在你的.TXT文件:
find "The allocation number is" < fastmmlog.txt | sort /R
這使你的第一次分配數量的,你的情況281
。
從這一點,你在爲.TXT分配編號搜索:
--------------------------------2011/1/7 23:31:03--------------------------------
A memory block has been leaked. The size is: 20
This block was allocated by thread 0x1540, and the stack trace (return addresses) at the time was:
402D80 [System][System][@GetMem]
40388F [System][System][TObject.NewInstance]
403C12 [System][System][@ClassCreate]
4038C4 [System][System][TObject.Create]
403C12 [System][System][@ClassCreate]
403C6A [System][System][@AfterConstruction]
457922 [GR32_Bindings][GR32_Bindings][NewRegistry]
45807E [GR32_LowLevel][GR32_LowLevel][RegisterBindings]
458152 [GR32_LowLevel][GR32_LowLevel][GR32_LowLevel]
404373 [System][System][InitUnits]
4043DB [System][System][@StartExe]
The block is currently used for an object of class: TList
The allocation number is: 281
在這裏你可以看到,該NewRegistry
涉及您的泄漏。
從那裏,你可以開始調試,找出泄漏的原因。
- jeroen
您可以發佈您的代碼,以便我們提供幫助。你應該能夠把一些東西放在一起,只是一個單一的.dpr文件,將展示問題。 – 2011-01-07 16:34:42
@Altar爲什麼你沒有在堆棧跟蹤中獲取函數名?我認爲你需要正確配置FastMM。此外,我剛剛想到,也許這些內存泄漏是來自VCL的預期內存泄漏。 – 2011-01-07 16:54:06
@David:看起來FullDebugMode已打開並且FastMM配置正確,但它沒有映射文件來查找地址。如果他有連接器生成詳細的地圖文件,它會變得更清楚發生了什麼事情。 – 2011-01-07 17:21:27