問題タブ [core-file]

バックグラウンドで15個のプロセス/デーモンが実行されているとしましょう。プロセスの 1 つがコアをダンプしたとしましょう。

どのプロセスがコアをダンプしたかを特定する方法を教えてください。

私はhpuxを使用しています！

gdbを使用してコアファイルを保存/ダンプすることは可能ですか？後で分析するためにファイルを保存したい場合があります。

タイトルに記載されている状況について、どのような理由が考えられますか? これが私のbtの外観です：

そしてそれは私に与えますProgram terminated with signal 11, Segmentation fault.

fflush() のラッパーは単純で、何もせず、呼び出しfflashてエラーをチェックするだけです (返されたコードが <0 の場合)。したがって、セグ フォールトの原因はfflash. または??、スタックの一番上にあるため、別の場所にいる可能性はありますか?

OS: RHEL5; gcc バージョン 3.4.6 20060404 (Red Hat 3.4.6-3); 最大デバッグ情報を含む元のexeを使用して、gdbでデバッグしました。

ディスクにスペースがない場合のセグフォルトについては知っていますが、これはそうではありません (アプリケーションのウォッチドッグがあり、プログラムを再起動すると、すべて正常に動作し続けます)。

どんなアイデアも役に立ちます。ありがとう。

編集

**注** コード全体を貼り付けることはできません。1 万以上のコードの一部です。また、これはリアルタイムシステムのさまざまなアプリケーションで何年も機能しています。このようなクラッシュは非常にまれで、年に 2 回程度です。したがって、これはコードの問題ではないと思います。誰もこの種のことで私を助けることができないことを私は知っています。そのため、私はアイデアを求めているだけです.fflushがセグフォールトを引き起こす理由.

ソフトウェアのリリース バージョン (gcc でコンパイルされた C++ コード) から送信されたコア ファイルをデバッグする方法を見つけようとしています。理想的には、リリース ビルドをデプロイし、デバッグ ビルドを手元に置いてデバッグに使用できるようにしたいので、シンボル テーブルなどを用意します。

私の問題は、(私が理解しているように) デバッグ ビルドとリリース ビルドが同じであることが保証されていないことです。そのため、gdb を起動してデバッグ実行可能ファイルを指定すると、フィールドのコア ファイルがゴミのように見えることがあります。

リリースされたソフトウェアのサイズやパフォーマンスに影響を与えずに、これを回避する方法はありますか (ここに問題があります)。これは大規模なアプリケーションであり、デバッグ ビルドのパフォーマンスはおそらく顧客に受け入れられないでしょう。一度ビルド (デバッグ) してから、シンボル テーブルを取り除き、それをリリース ビルドとして出荷するという提案を見てきましたが、そのアプローチではパフォーマンスが低下するのではないでしょうか?

この問題に対処するために試したこと、または現在使用していることについて誰か提案がありますか? ありがとう！

私はsnprintfセグメンテーション違反を起こしている。

このようにコアファイルをgdbにロードしたとき：gdb my_executable core; btバックトレースを取得するために、次のようになりました。

セグメンテーション違反の場合、このようなスタックが何度も表示されますが、正しく理解されていません。

呼び出しをトレースで見るだけで、何が問題になっているのかわかりますか？

注：これ以上のコードを要求しないでください。私の動機は、コードに関係なく、このようなスタックトレースが何を意味するのかを理解することです。上部の「memcpy」が失敗していることがわかります。このような状況でそれがいつ起こり得るのかを理解したいと思います。

C++ コードを呼び出す Python スクリプトを実行するテストがあり、セグメンテーション違反を起こし、コアをダンプします。/usr/bin/python2.6 を使用して GDB にコア ファイルをロードしようとしましたが、これだけで ?? スタック トレース内のすべてのアイテムに対して。このコア ファイルをデバッグするにはどうすればよいですか?

実行中の C プログラムのスナップショットをコアファイルの形式で生成するツールがあります。

これらのコアファイルを実行可能プログラムとして復活させることは可能ですか? もしそうなら、どうすればいいですか？すでにこれを行うライブラリはありますか?

私は* nixシステムに取り組んでいます。

アプリケーションをテストしています。アプリケーションが使用可能なメモリのほとんどを消費すると、カーネルがプロセスを強制終了します。しかし、調査の提案のために、プロセスが停止し、コア ファイルが生成されることを望みます。私はredhat 5.4を使用しています

とにかくそれを行うことはありますか？

コア ファイルを使用してデバッグしているため、何かを実行するアクティブなプロセスがありません。

gdb ユーザー定義コマンドを使用して、コア ファイルから一連のデータを検査し、ユーザー定義コマンドを使用してプロセスを簡素化しようとしています。

ただし、ユーザー定義コマンドが他のコマンドで使用できる値を返すようにする方法が見つかりません。

例:
(「return」行のコメントに注意してください)

理想的には、私の dump_linked_list コマンドは、リストで見つかったノードの数を返し、別の定義済みコマンドで使用できるようにします。

gdbコマンドでそのようなことは可能ですか?

そうに違いないと思いますが、ドキュメントを検索していて、それについての言及や例が見つかりません。

Linux デスクトップで ARM コア ファイルを読み取ろうとしていますが、コア ファイルを認識できないようです。私のコアファイルのタイプをgdbに指示する方法はありますか?

生成プラットフォームは armv4 であり、「セット アーキテクチャ」リストによると、gdb-multiarch がサポートすると主張しています。

編集：明確にするために、gdbを実行している私のデスクトップマシンは「x86_64-linux-gnu」、つまり64ビットIntel Ubuntuボックスです。