15

VisualCRTのメモリリーク検出ルーチンを使用してい<crtdbg.h>ます。私が呼び出す_CrtDumpMemoryLeaksと、プログラムのすべての呼び出しで1つの割り当てが一貫して報告されます。

{133} normal block at 0x04F85628, 56 bytes long.
 Data: <                > B0 81 F8 04 B0 81 F8 04 B0 81 F8 04 CD CD CD CD

アドレスは異なりますが、{133}常に同じです。

メモリ割り当て番号にブレークポイントを設定する方法に関するMSDNの指示によると、この呼び出しで133番目の割り当てにブレークポイントを設定できるはずです。

_CrtSetBreakAlloc(133);

また、実際に133に設定されているウォッチウィンドウで確認することもできます{,,msvcr90d.dll}_crtBreakAlloc。プログラムが終了した後も、リークレポートには＃133が（いくつかの高い数値とともに）表示されますが、ブレークポイントは発生しません。なぜこれが発生する可能性があり、ブレークポイントを発生させるにはどうすればよいですか？

潜在的に関連する情報：

  1. VS2008、「マルチスレッドデバッグDLL」CRTを使用
  2. 私のコードはサードパーティ製品によってロードされるDLLです
  3. 「通常の」ブレークポイントは問題なく機能します。ステップスルーは正常に機能します。__asm int 3うまくいきます。
  4. の他の値_crtBreakAllocもブレークポイントを引き起こしません（とにかく試したものではありません）
  5. ＃133はリークレポートの最小数です
4

2 に答える 2

9

主な額の平手打ち...「明らかな」理由の1つは、ブレークポイントが設定される前に割り当て＃133が発生した場合です。

DLLが呼び出される前に、最初のリークが発生しただけです。_CrtDumpMemoryLeaks実際、DLLがアンロードされたときに呼び出すので、必ずしもリークではありません。親アプリケーションの初期化解除が完了したときではありません。

私の元の質問の「潜在的に関連する情報＃4」については、いくつかの値を試しましたが、どういうわけか、133より高い値はありませんでした...

于 2010-02-09T01:36:10.573 に答える
1

デバッグ以外のライブラリを使用してアプリをコンパイルしているようです。アプリを壊すはずのリリースバージョンのlibを使用する場合、それは行われません。サードパーティのアプリを使用しているため、これが発生する可能性があります。実行時にデバッグdllの代わりに非デバッグdllがロードされる可能性もあります。

デバッグ中にアプリに適切なDLLがロードされているかどうか、またアプリまたはDLLが実際にデバッグされているかどうかを確認してください。（場合によっては、dllまたはexeをデバッガーに明示的にロードする必要があります。）

これは私がこれについての詳細を見ずに考えることができるすべてです...

于 2010-02-09T00:50:23.657 に答える