0

例外またはスタックトレースなしで終了したC++プログラム

私はマルチスレッドアプリケーションを持っています

スレッドの 1 つに、配列の範囲外の読み取り (または任意のセグ フォールト状態) によるアクセス違反がある場合、アプリケーション全体がすぐに終了します。

Visual Studio を使用している Windows のカウンター パーツでこれが発生した場合、エラーが発生した場所と問題の内容に関する適切なスタック トレースが得られます。

私のプロジェクトで成功するには、このタイプのデバッグ環境がどうしても必要です。スレッドが多すぎて、プロジェクトのさまざまな部分を実行している開発者が多すぎて、1 人が例外を適切に処理できず、プロジェクト全体が破壊されてしまいます。

Fedora Core 14 を実行しています gcc 4.5.1 でコンパイルしています gdb は fedora 7.2-16.fc14 です IDE は eclipse Juno CDT ビルダーを使用しています 私のツールチェーンはクロス GCC であり、私のビルダーは CDT Internal Builder です

これらのタイプの状況を検出するのに役立つgdb、gcc、またはEclipseの設定はありますか?

4

2 に答える 2

2

それが起こるはずです。Unix では、完全なコア ダンプ (デバッガーで調べることができます) を取得できますが、これは許可した場合に限ります。( ulimits -c- 従来はデフォルトで許可されていましたが、Linux ではこれが変更されたようです。)

もちろん、コア ダンプから有用な情報を取得するには、シンボル情報を使用してコードをコンパイルしておく必要があります。後で削除する必要はありません。(一方、コア ダンプをユーザー マシンから開発マシンにコピーして、そこで何が起こったかを確認できます。)

于 2013-03-19T15:21:49.103 に答える
0

James Kanze が書いたように、あなたは間違いなくコア ダンプを探しています。

コア ダンプは、プログラムがクラッシュした場所を示しますが、必ずしも問題 (メモリの破損など) が発生した場所と同じであるとは限りません。もちろん、一部の範囲外の読み取り/書き込みは、すぐにはクラッシュしないことがあります。

glibc で不正なメモリ割り当て/割り当て解除のチェックを有効にすることで、検索を絞り込むことができます。最も簡単な方法は、環境変数を設定することですMALLOC_CHECK_。に設定すると2、glibc はメモリの割り当て/割り当て解除ごとにヒープの破損をチェックし、問題が見つかったときにプログラムを中止します (有効な場合はコア ダンプを生成します)。これは、多くの場合、実際の問題に近づくのに役立ちます。

http://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html

于 2013-03-19T16:09:00.457 に答える