Dev で実行している Linux ディストリビューション以外の Linux ディストリビューションからコア ファイルが生成されるとどうなりますか?スタック トレースは意味がありますか?
実行可能ファイルが動的にリンクされている場合、GDB が生成するスタックは (ほとんどの場合) リンクされません
理由:GDB は、実行可能ファイルが libc.so.6 で何かを呼び出してクラッシュしたことを認識しています。 アドレス 0x00454ff1 、しかし、そのアドレスにあったコードはわかりません。 あなたのを調べます libc.so.6 のコピー これが select であることを発見します であるため、それを出力します。
しかし、0x00454ff1 の可能性 顧客でも選択されています libc.so.6 のコピー はかなり小さいです。おそらく abort で、顧客はそのアドレスで別の手続きを行った可能性があります。 .
disas select を使用できます 、そしてその 0x00454ff1 を観察します 命令の途中か、前の命令が CALL ではないかのいずれかです .これらのいずれかが成り立つ場合、スタック トレースは無意味です。
できます (gdb) info shared にリストされているすべてのライブラリのコピーを取得する必要があるだけです。 お客様のシステムから顧客に、たとえば次のようにそれらを tar してもらいます。
cd /
tar cvzf to-you.tar.gz lib/libc.so.6 lib/ld-linux.so.2 ...
次に、システム上で:
mkdir /tmp/from-customer
tar xzf to-you.tar.gz -C /tmp/from-customer
gdb /path/to/binary
(gdb) set solib-absolute-prefix /tmp/from-customer
(gdb) core core # Note: very important to set solib-... before loading core
(gdb) where # Get meaningful stack trace!
次に、デバッグを容易にするために -g バイナリを実行するようお客様にアドバイスします。
かなり より良いアプローチは:
-g -O2 -o myexe.dbgでビルドstrip -g myexe.dbg -o myexe- 配布
myexeお客様へ - 顧客が
coreを取得した場合 、myexe.dbgを使用 デバッグする
完全なシンボリック情報 (ファイル/行、ローカル変数) を入手できます。特別なバイナリを顧客に出荷したり、ソースに関する多くの詳細を明らかにしたりする必要はありません。
確かにクラッシュ ダンプから有用な情報を得ることができます。最適化されたコンパイルからでも (技術的には「お尻の大きな痛み」と呼ばれるものですが) -g もちろん、ダンプが発生したマシンが別のディストリビューションであってもコンパイルできます。基本的に、注意点が 1 つありますが、すべての重要な情報は実行可能ファイルに含まれており、最終的にはダンプになります。
コア ファイルと実行可能ファイルを一致させると、デバッガーはクラッシュが発生した場所を通知し、スタックを表示できます。それ自体が大いに役立つはずです。また、それが発生する状況についてできる限り調べる必要があります。彼らはそれを確実に再現できますか?もしそうなら、再現できますか?
ここで注意点があります。「すべてがそこにある」という概念が崩壊する場所は、共有オブジェクト ファイル .so です。 ファイル。それらの問題が原因で失敗している場合は、必要なシンボル テーブルがありません。ライブラリ .so しか表示されない場合があります
デバッグに関する本はたくさんありますが、お勧めできる本は思いつきません.