GDBにコアダンプをロードすると、自動的にクラッシュする理由が表示されます。例えば、GDBで最後に受信したシグナルを出力するには?
プログラムは11、セグメンテーションフォルトで終了しました。
情報を再度取得する方法はありますか? 問題は、この情報が必要なスクリプトを作成していることです。しかし、信号がコアダンプを読み込んだ後にしか利用できない場合は、後でその情報にアクセスすることはできません。
このような重要な機能はありませんか?
GDBにコアダンプをロードすると、自動的にクラッシュする理由が表示されます。例えば、GDBで最後に受信したシグナルを出力するには?
プログラムは11、セグメンテーションフォルトで終了しました。
情報を再度取得する方法はありますか? 問題は、この情報が必要なスクリプトを作成していることです。しかし、信号がコアダンプを読み込んだ後にしか利用できない場合は、後でその情報にアクセスすることはできません。
このような重要な機能はありませんか?
コアファイル名が何であるかを知っていれば、あなたがターゲットコアファイルrespecifies target core
コマンドを発行することができます暗黙の質問については
(gdb) target core core.8577
[New LWP 8577]
Core was generated by `./fault'.
Program terminated with signal 11, Segmentation fault.
#0 0x080483d5 in main() at fault.c:10
10 *ptr = '\123';
(gdb)
を、info last signal
コマンドは何ですか?、わかりません。 1つのようではありません。
コアファイルの名前は、コマンドinfo target
から入手することができます。最後の信号についての情報を印刷するには
(gdb) info target
Symbols from "/home/wally/.bin/fault".
Local core dump file:
`/home/wally/.bin/core.8577', file type elf32-i386.
0x00da1000 - 0x00da2000 is load1
0x08048000 - 0x08049000 is load2
...
0xbfe8d000 - 0xbfeaf000 is load14
Local exec file:
`/home/wally/.bin/fault', file type elf32-i386.
Entry point: 0x8048300
0x08048134 - 0x08048147 is .interp
0x08048148 - 0x08048168 is .note.ABI-tag
0x08048168 - 0x0804818c is .note.gnu.build-id
0x0804818c - 0x080481ac is .gnu.hash
0x080481ac - 0x080481fc is .dynsym
0x080481fc - 0x08048246 is .dynstr
...
感謝を実行しますgdb自体に与えられた引数またはスクリプトに引数を渡す "gdb実行可能なコア--batch -x myscript.py [引数をここに挿入]" 私はこの可能性も見つけ出したので、通常はgdbの引数で与えられるコアファイルの名前を調べる必要があります。 – Uhlo
@Uhlo:コマンド 'info target'は、実行可能ファイルとコアファイル名を表示します。もう少し詳しい情報。おそらくそれはしますか? – wallyk
ありがとうございます!これを解析するのはかなり難しいですが、少なくともそれは働いている方法です:)もう一度ありがとう! – Uhlo