CプログラムでLinuxがクラッシュしたときのデバッグの改善

Question

MIPsコアで実行されている組み込みバージョンのLinuxカーネルがあります。私たちが書いたプログラムは、特定のテストスイートを実行します。ストレステストの1つ（約12時間の実行中）では、segフォルトが発生します。これにより、コアダンプが生成されます。

残念ながら、コアダンプはそれほど有用ではありません。クラッシュは、動的にリンクされているシステムライブラリ（おそらくpthreadまたはglibc）にあります。それだけでクラッシュポイントを示し、他の発信者がいるため、コアダンプでのバックトレースは有用ではありません（私達のユーザー空間のアプリは-g -O0で構築されていないが、まだバックトレース情報なし）：

Cannot access memory at address 0x2aab1004 
(gdb) bt 
#0 0x2ab05d18 in ??() 
warning: GDB can't find the start of the function at 0x2ab05d18. 

    GDB is unable to find the start of the function at 0x2ab05d18 
and thus can't determine the size of that function's stack frame. 
This means that GDB may be unable to access that stack frame, or 
the frames below it. 
    This problem is most likely caused by an invalid program counter or 
stack pointer. 
    However, if you think GDB should simply search farther back 
from 0x2ab05d18 for code which looks like the beginning of a 
function, you can increase the range of the search using the `set 
heuristic-fence-post' command. 

もう一つの不幸をつまり、gdb/gdbserverを実行できないということです。 gdb/gdbserverは__nptl_create_eventを壊し続けます。テストでスレッド、タイマー、破棄が作成されるのを確認すると、5秒ごとに長時間座ることはほとんど不可能です。

EDIT： 私たちのツールチェーンでは、backtraceとbacktrace_symbolsはサポートされていません。したがって

：

1. などワンセグ障害とより多くのバックトレースデータを生成し、スタックポインタ、コールスタックを、トラップの方法はありますか？

2. .soファイルでクラッシュしたコアダンプからさらにデータを取得する方法はありますか？

ありがとう。

Answer 1

その他すべてが失敗した場合は、デバッガを使用してコマンドを実行してください！

通常の起動コマンドの形式で "gdb"を入力し、プロセスを実行するには "c"を入力してください。タスクがsegfaultすると、コアダンプではなく対話型のgdbプロンプトに戻ります。より意味のあるスタックトレースなどを得ることができるはずです。

もう1つの方法は、 "truss"を利用することです。これにより、異常終了時にどのシステムコールが使用されているかがわかります。

Answer 2

GDBはクラッシュ時にそのアドレスには何0x2ab05d18

での関数の開始を見つけることができませんか？

Do info sharedを実行し、そのアドレスを含むライブラリがあるかどうか調べます。

問題の原因としては、strip libpthread.so.0をターゲットにアップロードする前に実行しましたか？しないでください：GDBはlibpthread.so.0〜でなく、を削除する必要があります。あなたのツールチェーンにデバッグシンボル（ターゲットには大きすぎる）があるlibpthread.so.0が含まれている場合は、stripではなくstrip -gを実行してください。

更新：これは、GDBは（その後、行方不明スタックトレースを説明するだろう）共有ライブラリのリストにアクセスできないことを意味し0x2ab05d18

アドレスのメモリにアクセスできません生産

info shared。最も一般的な原因：実際にcoreを生成したバイナリは、GDBに与えたバイナリと一致しません。あまり一般的ではありません：おそらくulimit -cが低すぎるためにコアダンプが切り捨てられました。