完全なデバッグ情報でアプリケーションをコンパイルしてから、リンカオプションで、デバッグ情報が.EXEおよび/または.MAPファイルにあることを確認してください。
次に、FullDebugModeでFastMMを実行し、結果の.TXTファイルをコピーして質問に貼り付けます。
さらに詳しいヒントについては、this postも参照してください。
編集:
良い最初のステップは、あなたの.TXTファイルにこのような何かを行うことです。
あなたのケース
281
には、あなたの最初の割り当て番号を与える
find "The allocation number is" < fastmmlog.txt | sort /R
。それから、
、あなたは割り当て番号について.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ファイルに何かをまとめることができるはずです。 –
@Altarなぜスタックトレースに関数名をもらっていませんか? FastMMを正しく設定する必要があると思います。また、おそらくこれらのメモリリークはVCLからのものであると私は思いました。 –
@David:FullDebugModeがオンで、FastMMが正しく設定されているように見えますが、アドレスを検索するためのマップファイルはありません。リンカーが詳細な地図ファイルを生成していれば、何が起きているのかがはっきり分かります。 –