GDB core 问号

http://www.csdn123.com/html/mycsdn20140110/b8/b8d4fe51575016be71782b16f3a0823c.html 

程序发生Crash时，一般会coredump出转储文件core file。Crash调查的最直接目标是根据core file进行栈回溯或还原栈帧, 即find call trace。同时根据寄存器和出错处汇编代码，分析Crash的深层次原因，并提出解决方法。

 

1.  coredump设置
    要使coredump时产生合适的core file，需正确设置corefile format，这个在procfs中可以定制：
/proc/sys/kernel/core_pattern  
    core_pattern包含全路径，比如是/var/core/%e-%p-%t，则表示：/var/core/进程名-进程PID-CrashTime
    顺便关注一下内核源码中，core file及其名字的生成过程：
do_signal                            # arch/x86/kernel/signal.c
->  get_signal_to_deliver            # kernel/signal.c
->    do_coredump
->      format_corename              # fs/exec.c

    为了使生成的core file发挥更为直观的作用，要注意编译exec file（executed-file）时加上-g选项，这样通过gdb工具查找到的信息才更有价值。关于core file和exec file，有几个注意点。

• MUST have exec file together, the unstrip is better;
• MUST have shared lib file together, if some code is in lib;
• MUST accordant with core file and exec file!

 

2.  Crash调查
    如果做到了上面说的几点，发生coredump时能保留现场环境，那么正常情况下gdb的backtrace命令就能找到call trace。也就不用下面那么费劲。
    但总会出现一些不好处理的异常情况。比如在x86结构CPU的程序crash时，也许会出现一堆问号，如下所示：
(gdb) bt
#0  0xb5ff6106 in raise () from /lib/libc.so.6
#1  0xb6112ff4 in ?? () from /lib/libc.so.6
#2  0xb459f900 in ?? ()
#3  0xbfed551c in ?? ()
#4  0xb5ff7be1 in abort () from /lib/libc.so.6
#5  0x00000004 in ?? ()
Previous frame inner to this frame (corrupt stack?)

    出现异常的可能原因是exec file的symbol不存在或不匹配。根据之前对x86栈帧布局图的分析（http://blog.chinaunix.net/uid-16459552-id-3328601.html），bp-ra（即栈帧基址-返回地址）必定在栈帧顶端的固定位置，可以利用这个分布特点进行栈回溯。从当前的bp0开始，找到上一个bp1=*bp0，ra1=*(bp0 + 4)，ra1就是调用函数的地址。继续回溯，bp2=*bp1，ra2=*(bp1 + 4)，ra2应该是再上一级调用函数的地址。如此循环，同时用info symbol $ra* 打印出来每一级函数，就找到实际的call trace信息了。

 

3.  栈回溯示例
    获取pc(即eip)和bp(即ebp)的值，为回溯第一步作准备。执行gdb命令info register：
(gdb) i r
eax            0x0 0
ecx            0x3e4a 15946
edx            0x6 6
ebx            0x3e4a 15946
esp            0xbfed53f8     0xbfed53f8
ebp            0xbfed5400 0xbfed5400
esi            0xbfed54a0 -1074965344
edi            0xb6111ff4 -1240391692
eip            0xb5ff6206 0xb5ff6206 <raise+70>
eflags         0x202 [ IF ]
cs             0x73 115
ss             0x7b 123
ds             0x7b 123
es             0x7b 123
fs             0x0 0
gs             0x33 51

    实现上述栈回溯的shell脚本代码关键部分如下：

echo "Call func is: "
info symbol $pc        #打印当前函数的符号（即名字）
x/4x $ebp              #显示上一个栈帧顶部4个内存地址中的值，首先是上一个栈帧的bp和调用函数ra。保存在文件calltrace.log中最后一行
#下面是循环迭代部分
bp_now=$(tail -l "calltrace.log" | awk -F: '{print$1}')     #当前栈帧基址
bp_up=$(tail -l "calltrace.log" | awk '{print$2}')          #上一个栈帧基址
func_up=$(tail -l "calltrace.log" | awk '{print$3}')        #上一个栈帧对应函数
if [ $bp_up = "Cannot" -o $bp_up = "can't" ]; then
    exit
else
    gdb -q "$exec_file" "$core_file" << EOF
    set loggint redirect on
    set prompt
    set logging file "calltrace.log"
    set height 0
    echo Call function in:
    print/x $func_up
    info symbol $func_up          #打印上一个栈帧对应函数的符号（即名字），形成call trace!
    echo Upper frame bp is:
    print/x $bp_up
    x/4x $bp_up                   #为下一次回溯作准备!
    quit
EOF
fi  

    一次回溯的打印结果如下所示：
Call func is: 
raise + 70 in section .text    #当前函数
0xbfed5400:  0xbfed552c  0xb5ff7bd1  0x00000006  0xbfed54a0

Call function in:$1 = 0xb5ff7bd1
abort + 257 in section .text   #上一个调用函数
Upper frame bp is:$2 = 0xbfed552c
0xbfed552c:  0xbfed5b78  0xb602f2ab  0x00000004  0xbfed5664

......

 

    x86的backtrace异常还有一种情况是只能回溯一二级栈帧，如下所示：

(gdb) bt
#0  0xb5ff6106 in raise () from /lib/libc.so.6
(gdb) x $ebp
0x0:  Cannot acess memory at adderss 0x0

    这种情况一般是因为栈溢出，最外层的部分栈帧被冲掉了，所以无法进行栈回溯。这时，还是可以利用bp-ra在固定位置的分布特点来调查，从当前sp开始找“栈地址-函数地址”对，找到后就开始按上面的方法回溯。

 

4.  PowerPC和ARM的栈回溯
    鉴于PowerPC和ARM结构的CPU也有类似的栈帧布局，也可以采用上面的方法解决backtrace异常的问题。PowerPC栈帧布局特点见 http://blog.chinaunix.net/uid-16459552-id-3459993.html  ，ARM栈帧布局特点见 http://blog.chinaunix.net/uid-16459552-id-3364761.html  。由于暂时没有target环境，也未找到合适的虚拟硬件场景技术，所以无法为PowerPC和ARM类型的CPU程序Crash调查提供栈回溯例子，以后有机会补上