也谈栈和栈帧(五)——x86 Crash调查

来源：互联网发布：天启软件账号激活编辑：程序博客网时间：2024/06/03 19:19

转载自http://blog.chinaunix.net/uid-16459552-id-3482546.html 作者：r_luo

程序发生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 withcore 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 0xbfed54000xbfed5400
esi 0xbfed54a0 -1074965344
edi 0xb6111ff4 -1240391692
eip 0xb5ff62060xb5ff6206 <raise+70>
eflags 0x202 [ IF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
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 
setloggint redirect on
setprompt
setlogging file"calltrace.log"
setheight0
echo Callfunctionin:
print/x $func_up
info symbol $func_up #打印上一个栈帧对应函数的符号（即名字），形成calltrace!
echo Upper frame bpis:
print/x $bp_up
x/4x $bp_up #为下一次回溯作准备!
quit
EOF 
fi 

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

Call function in:$1 = 0xb5ff7bd1
abort + 257 in section .text #上一个调用函数
Upper frame bp is:$2 = 0xbfed552c
0xbfed552c:0xbfed5b780xb602f2ab 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调查提供栈回溯例子，以后有机会补上。