Visual Studio 2008で（ネイティブ）マルチスレッドC ++アプリケーションをデバッグしています。一見ランダムな状況で、「Windowsがブレークポイントをトリガーしました...」というエラーが発生します。これは、ヒープ。これらのエラーは、すぐにアプリケーションをクラッシュさせるとは限りませんが、すぐにクラッシュする可能性があります。
これらのエラーの大きな問題は、破損が実際に発生した後にのみ表示されるため、特にマルチスレッドアプリケーションでは、追跡とデバッグが非常に困難になることです。
これらのエラーの原因は何ですか？
どうすればデバッグできますか？
ヒント、ツール、方法、啓蒙...は大歓迎です。
回答:
Windows用のデバッグツールと組み合わせたApplication Verifierは、すばらしいセットアップです。どちらも、Windows Driver Kitまたは軽量のWindows SDKの一部として入手できます。（ヒープの破損の問題に関する以前の質問を調べたときに、Application Verifier について知りました。）以前にBoundsCheckerとInsure ++（他の回答で述べた）を使用したこともありますが、Application Verifierの機能に驚かされました。
Electric Fence（別名 "efence"）、dmalloc、valgrindなどはすべて言及する価値がありますが、これらのほとんどはWindowsよりも* nixで実行する方がはるかに簡単です。Valgrindは途方もなく柔軟です。私はそれを使用して多くのヒープの問題がある大規模サーバーソフトウェアをデバッグしました。
他のすべてが失敗した場合、独自のグローバルオペレーターnew / deleteおよびmalloc / calloc / reallocオーバーロードを提供できます-これを行う方法は、コンパイラーとプラットフォームによって少し異なります-これは少しの投資になります-しかし、長期的には見返りが見込めます。望ましい機能のリストは、dmallocとelectricfence、そして驚くほど優れた著書「Writing Solid Code」からおなじみのはずです。
ローカルの自作システム（埋め込みターゲットの場合）では、実行時のオーバーヘッドがはるかに高いため、他のほとんどのものから追跡を分離していることに注意してください。
これらの割り当て関数/演算子をオーバーロードする他の理由に興味がある場合は、「グローバルオペレーターnewおよびdeleteをオーバーロードする理由はありますか？」に対する私の答えを見てください。; 恥知らずな自己宣伝はさておき、ヒープ破損エラーの追跡に役立つその他のテクニックと、その他の適用可能なツールを示します。
MSが使用するalloc / free / fence値を検索するとき、私はここで自分の答えを見つけ続けるので、Microsoft dbgheap fill値をカバーする別の答えがあります。
アプリケーションでページヒープを有効にすることにより、多くのヒープ破損の問題を検出できます。これを行うには、Windows用デバッグツールの一部として付属するgflags.exeを使用する必要があります。
Gflags.exeを実行し、実行可能ファイルの[イメージファイル]オプションで、[ページヒープを有効にする]オプションをオンにします。
ここで、exeを再起動して、デバッガーに接続します。ページヒープを有効にすると、ヒープの破損が発生するたびにアプリケーションがデバッガーに侵入します。
実際に速度を落として多くのランタイムチェックを実行するには、main()Microsoft Visual Studio C ++の上部または同等のものに以下を追加してみてください
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF | _CRTDBG_CHECK_ALWAYS_DF );これらのエラーの原因は何ですか？
メモリを使用していたずらを行う。たとえば、バッファの最後に書き込んだり、バッファが解放されてヒープに戻った後にバッファに書き込んだりする。
どうすればデバッグできますか？
実行可能ファイルに自動境界チェックを追加する機器を使用します。つまり、Unixのvalgrind、またはWindowsのBoundsChecker（WikipediaもPurifyおよびInsure ++を提案）などのツールを使用します。
これらはアプリケーションの速度を低下させるため、ソフトリアルタイムアプリケーションの場合は使用できない場合があることに注意してください。
別の可能なデバッグ支援/ツールは、MicroQuillのHeapAgentかもしれません。
解放されたメモリへのアクセスの検出から得た簡単なヒントは次のとおりです。
メモリブロックにアクセスするすべてのステートメントをチェックせずにエラーをすばやく見つけたい場合は、ブロックを解放した後でメモリポインタを無効な値に設定できます。
#ifdef _DEBUG // detect the access to freed memory #undef free #define free(p) _free_dbg(p, _NORMAL_BLOCK); *(int*)&p = 0x666; #endif
私が便利だと思っていつも働いていた最良のツールは、コードレビュー（優れたコードレビュー担当者による）です。
コードレビュー以外に、最初にPage Heapを試します。ページヒープのセットアップには数秒かかり、運が良ければ問題を特定できるかもしれません。
ページヒープでうまくいかない場合は、MicrosoftからDebugging Tools for Windowsをダウンロードして、WinDbgの使い方を学んでください。申し訳ありませんが、具体的なヘルプは提供できませんでしたが、マルチスレッドのヒープ破損のデバッグは、科学というより芸術です。「WinDbgヒープの破損」についてGoogleを検索すると、この件に関する多くの記事が見つかります。
動的または静的Cランタイムライブラリに対してリンクしているかどうかを確認することもできます。DLLファイルが静的Cランタイムライブラリに対してリンクしている場合、DLLファイルには個別のヒープがあります。
したがって、1つのDLLでオブジェクトを作成し、それを別のDLLで解放しようとすると、上記と同じメッセージが表示されます。この問題は、別のスタックオーバーフローの質問「別のDLLに割り当てられたメモリの解放」で参照されています。
どのタイプの割り当て関数を使用していますか？最近、Heap *スタイルの割り当て関数を使用して同様のエラーに遭遇しました。
HEAP_NO_SERIALIZEオプションでヒープを誤って作成していたことがわかりました。これにより、本質的にヒープ関数はスレッドセーフなしで実行されます。適切に使用すればパフォーマンスが向上しますが、マルチスレッドプログラムでHeapAllocを使用している場合は使用しないでください[1]。あなたの投稿があなたにマルチスレッドアプリがあることを言及しているので、私はこれについてのみ言及します。HEAP_NO_SERIALIZEをどこかで使用している場合は、それを削除すると問題が解決する可能性があります。
[1]これが正当である特定の状況がありますが、Heap *への呼び出しをシリアル化する必要があり、通常、マルチスレッドプログラムには当てはまりません。
これらのエラーがランダムに発生する場合は、データ競合が発生した可能性が高いです。確認してください：異なるスレッドの共有メモリポインタを変更しますか？インテルスレッドチェッカーは、マルチスレッドプログラムでこのような問題を検出するのに役立ちます。
ツールを探すことに加えて、可能性のある犯人を探すことを検討してください。マルチスレッド環境で実行するように設計およびテストされていない可能性がある、おそらくあなたが作成していない、使用しているコンポーネントはありますか？あるいは、あなたが知らないものだけがそのような環境で実行されました。
それが私に最後に起こったとき、それは何年もの間バッチジョブから成功裏に使用されたネイティブパッケージでした。しかし、この会社で.NET Webサービス（マルチスレッド）から使用されたのはこれが初めてでした。それはそれでした-彼らはコードがスレッドセーフであることについて嘘をつきました。
あなたは、のためにVC CRTヒープ・チェックのマクロを使用することができます_CrtSetDbgFlag：_CRTDBG_CHECK_ALWAYS_DFまたは_CRTDBG_CHECK_EVERY_16_DF ... _CRTDBG_CHECK_EVERY_1024_DF。
私の経験を追加したいのですが。この数日間、アプリケーションでこのエラーのインスタンスを解決しました。私の特定のケースでは、コードのエラーは次のとおりです。
Control.Invokeでは、コールバックが属するネイティブオブジェクトをラップするマネージオブジェクトを呼び出して破棄します。Control.Invoke終了するまでコールバック呼び出しでブロックされたままになります）。を使用することを明確にする必要boost::threadがあるので、スレッド関数としてメンバー関数を使用します。Control.BeginInvoke代わりに（私のGUIはWinformsで作成されています）を使用して、オブジェクトが破棄される前にネイティブスレッドが終了するようにします（コールバックの目的は、スレッドが終了してオブジェクトが破棄されることを正確に通知することです）。