2

ここに悲しい話があります：

  1. thedarkmod.x64デバッグ シンボルを別のファイルに移動して、自分のマシンで実行可能ファイルをビルドしましたthedarkmod.x64.debug。
  2. この実行可能ファイルを gdb で実行しているときに、この実行可能ファイルでクラッシュが発生しました。彼女はgdb コマンドcore.1600を使用してコア ダンプを保存しました。generate-core-file
  3. このコア ファイルをダウンロードし、起動して開きましたgdb ./thedarkmod.x64 core.1600。
  4. スレッドを切り替えてbtコマンドを実行しましたが、適切なスタック トレースではなくゴミが表示されます。

注: ユーザーは私のthedarkmod.x64.debugファイルを持っておりbt、コア ダンプを保存する直前に実行すると、意味のあるスタック トレースが表示されます。

コア ダンプで gdb を起動すると、次のような多くの警告メッセージが表示されます。

  • 下位のスレッド ライブラリに一致する libthread_db が見つかりません。スレッドのデバッグは利用できません。
  • 警告: "libXXX.so" の .dynamic セクションが予期されたアドレスにありません (間違ったライブラリまたはバージョンの不一致?)

この質問によると、最初の警告はlibthread_db.so.1、コア ダンプが保存されたマシンと同じバージョンの を持っていない限り、マルチスレッド プログラムで有用なものが何も表示されないことを意味しているようです。ユーザーにこのファイルを見つけて提供するように依頼しましたが、役に立ちませんでした。libpthread.so.0次に、ファイルも提供するように依頼し、、、、と苦労しset solib-search-pathた後set sysroot、この警告を「libthread_dbを有効にしたスレッドデバッグ」に置き換えることができましたが、スタックトレースはまだ間違っていました。set auto-load safe-pathset libthread-db-search-path

質問は次のとおりです。

  1. 環境が大きく異なる Linux マシンで生成されたコア ダンプを適切に検査する方法はありますか? 異なるカーネル、pthreads、glibc などを意味します。それを達成する方法に関する詳細な指示はどこにありますか?
  2. のような gdb コマンドはありgenerate-core-file includecodeますか?

現時点では、提出されたすべてのコア ダンプに対して新しい Linux VM を作成する準備ができていないため、Linux コア ダンプはほとんど役に立たないことを認めなければなりません。

更新:適切なスタック トレースを取得することができました。

  1. 「重複した質問」で提供された解決策はうまくいきませんでした。solib 関連の設定だけでは十分ではありませんでしset sysrootた。
  2. 私の特定のケースでは、スタック トレースfreeは libc の関数内で終了しました。-fomit-frame-pointerおそらくほとんどのライブラリと同じようにコンパイルされているため、gdb はコール スタックをたどることができませんでした。libc.so.6ユーザーのマシンから取得したgdb ロードが役立つことを確認してください。

以下は、私が使用する gdb コマンドの完全なリストです (btもちろん、動作させるにはそれぞれのコマンドが必要です)。

# note: all the .so files obtained from user machine must be put into local directory.
#
# most importantly, the following files are necessary:
#   1. libthread_db.so.1 and libpthread.so.0: required for thread debugging.
#   2. other .so files are required if they occur in call stack.
#
# these files must also be renamed exactly as the symlinks
# i.e. libpthread-2.28.so should be renamed to libpthread.so.0

# load executable file
file ./thedarkmod.x64

# force gdb to forget about local system!
# load all .so files using local directory as root
set sysroot .

# drop dump-recorded paths to .so files
# i.e. load ./libpthread.so.0 instead of ./lib/x86_64-linux-gnu/libpthread.so.0
set solib-search-path .
# disable damn security protection
set auto-load safe-path /

# load core dump file
core core.6487

# print stacktrace
bt
4

0 に答える 0