7

通常、この問題をどのように回避しますか?Computer1のlibcコード(システム共有ライブラリ)内でスレッドがクラッシュし、コアダンプが生成されると想像してください。ただし、このコアダンプが分析されるComputer2には、異なるバージョンのlibcが含まれている可能性があります。

それで:

  1. リモートコンピュータに同じ共有ライブラリを配置することはどれほど重要ですか?gdbは、Conputer2にまったく同じバージョンのlibcがなくても、スタックトレースを正しく再構築しますか?

  2. libcの正しいデバッグシンボルを持つことはどれほど重要ですか?Computer2にまったく同じデバッグシンボルがなくても、gdbはスタックトレースを正しく再構築しますか?

  3. そして、共有システムライブラリのこのデバッグシンボルの不一致の問題を回避するための「正しい」方法は何ですか?私にとって、この問題をエレガントな方法で解決する単一の解決策はないように思われますか?多分誰もが彼の経験を共有することができますか?

4

1 に答える 1

13
  1. 場合によります。などの一部のプロセッサでは、GDBがスタックを適切にアンワインドするにはx86_64、正しいアンワインド記述子が必要です。このようなマシンでは、一致しないlibcを使用してコアダンプを分析すると、完全なガベージが生成される可能性があります。

  2. スタックトレースを取得するためにlibcのデバッグシンボルは必要ありません。デバッグシンボルがないとファイル番号と行番号を取得できませんが、正しい関数名を取得する必要があります(インライン化が行われている場合を除く)。

  3. あなたの質問の前提は間違っています-デバッグシンボルはこれとは何の関係もありません。C1でコアダンプが生成されたときにC2でコアダンプを分析する「正しい」方法は、C1のライブラリのコピー(たとえば)を用意し、C2がインストールされて/tmp/C1/lib/...いる代わりにそのコピーを使用するようにGDBに指示することです。libc

    (gdb) set solib-absolute-prefix /tmp/C1

指図。

:コアをGDBにロードする前に、上記の設定が有効になっている必要があります。これ:

gdb exe core
(gdb) set solib-absolute-prefix /tmp/C1

動作しません(設定が有効になる前にコアが読み取られます)。

正しい方法は次のとおりです。

gdb exe
(gdb) set solib-absolute-prefix /tmp/C1
(gdb) core core

(私はウェブ上でこれへの参照を見つけようとしましたが、しませんでした)。

アンワインド記述子とは何ですか?

コードがフレームポインタなしでコンパイルされる場合は、アンワインド記述子が必要です(最適化モードでのx86_64のデフォルト)。このようなコードは%rbpレジスタを保存しないため、GDBに現在のフレームから呼び出し元のフレームに「ステップバック」する方法を指示する必要があります(このプロセスはスタックアンワインドとも呼ばれます)。

C1のlibc.soがコアに含まれていないのはなぜですか?

コアファイルには通常、プログラムアドレス空間の書き込み可能なセグメントの内容のみが含まれています。読み取り専用セグメント(実行可能コードとアンワインド記述子が存在する場所)は通常必要ありません。ディスク上のlibc.soから直接読み取ることができます。

ただし、C2でC1のコアを分析する場合は、これは機能しません。

一部の(すべてではない)オペレーティングシステムでは、「完全なコアダンプ」を構成できます。この場合、OSは読み取り専用のマッピングもダンプするため、任意のマシンでコアを分析できます。

于 2010-12-03T05:54:48.340 に答える