2

Linux redhat 3 を使用していますが、Linux redhat 5 で生成されたコア ダンプである gdb を使用して分析できることを誰かが説明できますか?

私が不満を言うわけではありません:)しかし、これが常に機能することを確認する必要があります...？

編集: 共有ライブラリは同じバージョンであるため、心配する必要はありません。共有ストレージに配置されているため、Linux 5 と Linux 3 の両方からアクセスできます。

ありがとう。

4

5 に答える 5

4

次のGDBのコマンドを試して、コアファイルを開くことができます

gdb
 (gdb) exec-file <executable address>
 (gdb) set solib-absolute-prefix <path to shared library>
 (gdb) core-file <path to core file>

信頼できない理由は、すべてのプロセスが libc またはシステム共有ライブラリを使用していたためです。これは、Red Hat 3 から Red Hat 5 に確実に変更されます。そのため、ネイティブ関数のすべての命令アドレスと命令数は diff になります。 、そしてデバッガーがおかしくなり、分析するために間違ったデータを表示する可能性があります。したがって、同じプラットフォームでコアを分析するか、必要なすべての共有ライブラリを他のマシンにコピーして、set solib-absolute-prefix を介してパスを設定できる場合は常に良いことです。

于 2010-08-25T12:04:56.777 に答える
2

他のシステムで生成されたコアファイルを分析した私の経験では、標準ライブラリ（およびプログラムがおそらく使用する他のライブラリ）は通常異なるため、機能しないため、関数のアドレスが異なるため、適切なバックトレースを取得することさえできません。

時々うまくいくとしても、頼りにならないので、やらないでください。

于 2010-08-25T09:53:37.787 に答える
1

いつでも実行できますgdb -c /path/to/corefile /path/to/program_that_crashed。ただし、program_that_crashed にデバッグ情報がない場合 (つまり、gcc/ld フラグを使用してコンパイルおよびリンクされてい-gない場合)、ハードコア デバッグの専門家でない限り、コアダンプはあまり役に立ちません ;-)

コアファイルの生成は無効にできることに注意してください (ほとんどのディストリビューションではデフォルトで無効になっている可能性が非常に高いです)。を参照してくださいman ulimit。コア ファイルの制限を確認するために呼び出しulimit -cます。「0」は無効を意味します。ulimit -c unlimitedこの場合は試してみてください。サイズ制限が課されている場合、コアダンプは制限サイズを超えないため、貴重な情報が切り落とされる可能性があります。

また、コアダンプが生成されるパスは /proc/sys/kernel/core_pattern に依存します。cat /proc/sys/kernel/core_pattern現在のパターンを照会するために使用します。これは実際にはパスであり、このパスで始まらない場合/、ファイルはプロセスの現在の作業ディレクトリに生成されます。また、cat /proc/sys/kernel/core_uses_pid「1」が返された場合、コアダンプにはクラッシュしたプロセスのファイル PID がファイル拡張子として含まれます。両方の値を設定することもできます。たとえば、echo -n /tmp/core > /proc/sys/kernel/core_patternすべてのコアダンプが /tmp に強制的に生成されます。

于 2010-08-25T09:01:02.183 に答える
0

私は質問を次のように理解しています：

あるバージョンの OS で生成されたコアを別のバージョンの OS で解析できるのはどうしてですか?

あなたが幸運だからです（それも疑わしいです）。そうしようとすると、うまくいかないことがたくさんあります。

  • ツールチェーンgccなどgdbは異なるバージョンになります
  • 共有ライブラリは異なるバージョンになります

いいえ、それに頼るべきではありません。

于 2010-08-25T09:49:45.333 に答える
-1

あなたは同様の質問をし、もちろんここで自分で答えを受け入れました：共有オブジェクトのコアファイルを分析しています

コア ファイルをロードすると、スタック トレースを取得し、最後の関数呼び出しを取得して、クラッシュの理由についてコードを確認できます。

開始するための小さなチュートリアルがここにあります。

編集：

Linuxでgdbを使用してコアファイルを分析する方法を知りたいと仮定すると、質問はほとんど不明です。

于 2010-08-25T08:58:21.963 に答える