2

ここ、MSDN、およびGoogleを介して他のフォーラムで検索を行い、これに対する何らかの解決策を見つけようとしましたが、これまでのところ行き詰まっています.

C++ プログラムのアクセス違反エラーを突き止めようと、1 週間探していました。一部の IP 制限の下にあるため、ここにコードを投稿することはできませんが、基本的には、TCP 接続からバイトを読み取り、std::queue の後ろに配置する約 100 ミリ秒ごとに実行されるループです。

特定のバイト シーケンスが通過したことに気付いた後、x バイトをキューから削除し、内部プロトコルで定義されたメッセージとして処理します。

アプリケーション内のどこかで、キューが破損し、アプリケーションがクラッシュします。したがって、それがアクセス違反であるという事実と組み合わせると、どこかの危険なポインターである必要があります。

VS2005 Debugger と Windbg を使用してそれを見つけようとしましたが、コール スタックを調べましたが、あまり役に立ちませんでした。私が解決できるのは、原因が内部キューの破損であるということだけです。クラッシュする理由は、メッセージのヘッダーが送信されて解析されるためですが、ヘッダーが破損しているため、すべてが失敗します。

次に、Intel Thread Checker を試してみましたが、プログラムが同期マルチスレッド システムの一部であるため、このアプリケーションで使用するには遅すぎます。

300回の読み取りで実行されることもあれば、5000回の読み取りが実行されることもあり、クラッシュする前に10000回の読み取りが実行されることもあります。

他にどのような診断方法を試すことができますか? ここで、すでにチェックしておくべき単純なものがありませんか？私が見る限り、新しく作成されたものはすべて一致する削除があり、共有ポインターと長寿命オブジェクトの自動ポインターにブースト ライブラリを使用しています。

4

2 に答える 2

1

通常、ヒープの破損によって引き起こされるランダムなクラッシュは、見つけるのが困難です。過去数年間、私はいくつかのヒープ破損の問題に対処していました。覚えているように、問題の1つは、それを追跡するために週末全体を費やしました。ここにいくつかの提案があります：

  1. 最初にアプリベリファイアを試してください。詳細は次の場所にあります：http： //msdn.microsoft.com/en-us/library/windows/desktop/dd371695 （v = vs.85）.aspx 。
  2. Gflags： http ://msdn.microsoft.com/en-us/library/windows/hardware/ff549557(v=vs.85).aspx 。これを使用して、ページヒープの検証を有効にします。

  3. 解決策1と2はどちらもプログラム全体にヒープ検証を使用しているため、多くの例外が発生してプログラムの速度が低下する可能性がありますが、それらの一部は問題に関連していません。コードのどの部分にエラーがあるかがわかっている場合は、ウィンドウAPI _CrtSetDbgFlagを使用して、ヒープ検証を有効にすることができます。

    `int tmpFlag = _CrtSetDbgFlag（_CRTDBG_REPORT_FLAG）;

    tmpFlag | = _CRTDBG_CHECK_ALWAYS_DF;

    _CrtSetDbgFlag（tmpFlag）; //allocおよびdealloc時にヒープを確認します

    //ここでコーディングします。ヒープが破損している場合、次の割り当てで例外がスローされます。

    tmpFlag | =〜_CRTDBG_CHECK_ALWAYS_DF;

    _CrtSetDbgFlag（tmpFlag）//ヒープを検証しない`

于 2012-11-19T04:08:31.183 に答える