3

クラッシュをデバッグしようとしているアプリケーションがあります。ただし、いくつかの理由で問題を検出するのが困難です。

  • クラッシュはシャットダウン時に発生します。つまり、問題のあるコードはスタックにありません。
  • クラッシュはリリースビルドでのみ発生します。つまり、シンボルは使用できません。

クラッシュとは、次の例外を意味します。

0xC0000005: Access violation reading location 0x00000000.

この問題を診断するためにどのような戦略を使用しますか？

これまでに行ったことは、クラッシュの原因となる最小限のコードが得られるまで、プログラムからできるだけ多くのコードを削除することです。プロジェクトに静的にリンクされているコードで発生しているように見えるので、それも役に立ちません。

4

3 に答える 3

5

リリース ビルドでもシンボル ファイルを作成できます。それを行い、プログラムを実行し、デバッガーをアタッチして閉じ、デバッガーでクラッシュの原因を確認します。

于 2008-12-18T23:15:29.777 に答える
1

私が使用する戦略は、まさにあなたが行ったことです。問題がなくなるまでできるだけ多くのコードを削除してから、最後のビットを追加してデバッグします。

ただし、問題があるのはコードではない可能性があります。注意すべき点が1つあります。この問題はAIXで見つかりました。また、Windowsを実行している場合でも、同様の問題が発生する可能性があります。

別の共有ライブラリを動的にロードするサードパーティライブラリがあり、その初期化ルーチンで、プロセスの終了時に呼び出されるatexit関数を設定しました。

ただし、アプリケーションがこれらの共有ライブラリをロードおよびアンロードすると、プロセスが終了するまでに、共有ライブラリのatexit関数がメモリに存在しなくなり、コアがダンプされました。

これは、main（）から戻った後にアクセス違反として表示されるため、それが発生している場合は、ほぼ確実に同じ種類のことです。C RTLスタートアップコードは、atexitリストをウォークし、それらを使用して何をしたかに関係なく、その各関数を呼び出します。

もちろん、main（）が終了する前にクラッシュしている場合、これは重要なポイントです。

検討できることの1つ（そして、特に厄介なバグを追跡して修正する費用便益分析の後で、実際にこれを行ったことがあります）：デバッグリリースを製品として送信します。それがクラッシュしていない場合、それはあなたがあなたの余暇でより受け入れられる解決策に取り組んでいる間に製品をそこに出すための迅速な解決策かもしれません。

于 2008-12-18T23:51:08.597 に答える
1

あなたはヌルポインタを読んでいるようです - 決して良くありません。

どのプラットフォームを使用しているのかわかりません。Linux では、valgrind.

デバッグ情報の有無以外に、リリース ビルドとデバッグ ビルドの違いは何ですか?

デバッグ情報を含む静的にリンクされたコードをビルドできますか? 静的にリンクされたコードのデバッグ ビルドを入手できますか?

于 2008-12-18T22:47:53.247 に答える