Android——coredump解析

撰写不易,转载需注明出处：http://blog.csdn.net/jscese/article/details/46916869本文来自【jscese】的博客！

coredump文件生成
前文Android——coredump 配置记录了android平台上的环境配置，生成方式正常即为process触发那几种signal

手动coredump状态：
连接gdb -gcore pid
终端发送signal终止process： kill -s signal pid 自然发送能产生coredump的signal ，前文有记录，但是有时一次还杀不掉process signal可以被忽视。
signal可参考：

root@:/ # kill -l

 HUP Hangup   Signal

 INT Interrupt   Signal

 QUIT Quit   Signal

 ILL Illegal instruction   Signal

 TRAP Trap   Signal

 ABRT Aborted   Signal

 BUS Bus error   Signal

 FPE Floating point exception   Signal

 KILL Killed   Signal

 USR1 User signal    Signal

 SEGV Segmentation fault   Signal

 USR2 User signal    Signal

 PIPE Broken pipe   Signal

 ALRM Alarm clock   Signal

 TERM Terminated   Signal

 STKFLT Stack fault   Signal

 CHLD Child exited   Signal

 CONT Continue   Signal

 STOP Stopped (signal)   Signal

 TSTP Stopped   Signal

 TTIN Stopped (tty input)   Signal

 TTOU Stopped (tty output)   Signal

 URG Urgent I/O condition   Signal

 XCPU CPU time limit exceeded   Signal

 XFSZ File size limit exceeded   Signal

 VTALRM Virtual timer expired   Signal

 PROF Profiling timer expired   Signal

 WINCH Window size changed   Signal

 IO I/O possible   Signal

 PWR Power failure   Signal

 SYS Bad system call   Signal

  Signal    Signal

gdb调试coredump
以simplejni apk中 jni崩溃得到的core.droid.simplejni.1797文件拷贝到编译源码的根目录为例

源码目录下使用编译工具链的gdb
也可以cygwin终端下或者eclipse环境下使用ndk的gdb操作，经过多次调试发现有的动态库中的symbol信息， ndk的gdb无法显示完全！

开启android gdb：
./prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8/bin/arm-linux-androideabi-gdb
1
2.gdb模式下设置动态库搜索加载路径：

set solib-search-path /home/..../out/target/product/../symbols/system/lib/
1
设置到源码编译的out目录下的symbol

3.加载启动程序：

file out/target/product/../symbols/system/bin/XXX
//app进程最后XXX就是app_process32，zygote的启动程序，根据情况修改
4.加载core文件：

5.常用命令：
==============command=========
set logging on/off log保存

backtrace(bt) n 回溯n个调用栈

list n 显示源码或者显示行数
list - 向上显示

set listsize n 设置打印行数

frame(f) n 切换栈帧
info frame(f) 0 第几栈帧的信息

info args 显示当前栈帧函数参数

info locals 当前帧函数局部变量

info threads / thread n 查看线程信息/切换线程

info (all-)register/ info r rname 查看全部寄存器/根据寄存器名查看

info line filename:func/line 查看文件中某行代码当时在内存中的地址：

disassemble fuc / disassemble $pc 反汇编函数/反汇编pc寄存器指向的指令所属函数：

x/fu address 查看内存中的值
f表示显示方式, 可取如下值
x 按十六进制格式显示变量。
d 按十进制格式显示变量。
u 按十进制格式显示无符号整型。
o 按八进制格式显示变量。
t 按二进制格式显示变量。
a 按十六进制格式显示变量。
i 指令地址格式
c 按字符格式显示变量。
f 按浮点数格式显示变量。

u表示一个地址单元的长度
b表示单字节，
h表示双字节，
w表示四字节，
g表示八字节

pc 的值为下一条指令存放的地址，此时的pc值所指向的指令为：

后面0x2004681b代表的即为汇编的arm指令

此时执行的指令是 ldr r3, [r3, #0]
加载 [r3, #0] 地址的值给 r3寄存器，可以看到前面还有一句：
movs r3, #0 设成了0
可查看r3 寄存器当前的值，p X：

这里就是从 0 地址加载，访问了 0地址内存，空指针，导致段错误

记录

报非法指令，反汇编看到pc所指的指令，这里指向的是gdb反汇编了symbol下对应的动态库(libsurfaceflinger.so)再根据内存地址以及在动态库中的偏移得到的，同样可以查看当时内存中的指令：

由于报非法指令，我们可以手动去反汇编libsurfaceflinger.so 校验一下实际的与内存中的指令是否一致：
源码目录下：

prebuilts/gcc/linux-x86/arm/arm-eabi-4.8/bin/arm-eabi-objdump -S -D out/target/product/../symbols/system/lib/libsurfaceflinger.so > libsurfaceflinger.txt
1
objdump -x obj 以某种分类信息的形式把目标文件的数据组织（被分为几大块）输出 <可查到该文件的所有动态库>

objdump -t obj 输出目标文件的符号表()

objdump -h obj 输出目标文件的所有段概括()

objdump -j .text/.data -S obj 输出指定段的信息，大概就是反汇编源代码把

objdump -S obj C语言与汇编语言同时显示
1
2
3
4
5
6
7
8
9
查看libsurfaceflinger.txt汇编文件
可根据上面的 info line 得到的地址与这里的地址算偏移，算出libsurfaceflinger.txt中应该对应的指令

或者以没有崩溃前的cat /proc/4702(pid)/maps 查看内存映射，算偏移地址得到指令:

//动态库被加载到内存的映射
root:/ # cat /proc/4702(pid)/maps | grep surface
b6ec5000-b6ef4000 r-xp 00000000 5d:10 1567 /system/lib/libsurfaceflinger.so
b6ef4000-b6ef9000 r--p 0002e000 5d:10 1567 /system/lib/libsurfaceflinger.so
b6ef9000-b6efa000 rw-p 00033000 5d:10 1567 /system/lib/libsurfaceflinger.so
b6feb000-b6fed000 r-xp 00000000 5d:10 464 /system/bin/surfaceflinger
b6fed000-b6fee000 r--p 00001000 5d:10 464 /system/bin/surfaceflinger
一共有6列
第一列代表内存段的虚拟地址
第二列代表执行权限，r，w，x不必说，p=私有 s=共享
不用说，heap和stack段不应该有x，否则就容易被xx，不过这个跟具体的版本有关
第三列代表在进程地址里的偏移量
第四列映射文件的主设备号和次设备号
通过 cat /proc/devices
得知fd是253 device-mapper
第五列映像文件的节点号，即inode
第六列是映像文件的路径
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
这里发现内存中指令是对的，考虑可能是cpu取指出错

//汇编
//寄存器存储
stmia，比如当前ro指向的内存地址是 0x1000，STMIA RO!,{R1-R7} 就是首先把r1存入 0x1000,
然后r2存入0x1004，然后r3存入0x1008，如果是32位的处理器就是每次加4个字节，以此类推把 r1-r7按照递增的地址存入。。。。
这个r0!就是从r0的地址开始存的意思。。。

stmia.w r11, {r2, r3, r4, r5} //.w的意思是告诉编译器，这条指令采用32bit编码。
相同：
str.w r2 [r11] //将寄存器r2的值存入r11指向的地址上，寄存器本身r11本身的值不变
str.w r3, [r11,#4]
str.w r4, [r11,#8]
str.w r5, [r11,#12]

32bit 一次+4 byte

stmdb 则是地址从r0开始减少，依次存储。。。

暂时记录这么多~ 后续有需要再添加~
---------------------
作者：南丶烟
来源：CSDN
原文：https://blog.csdn.net/jscese/article/details/46916869
版权声明：本文为博主原创文章，转载请附上博文链接！

巴特西

Android——coredump解析

最新文章

热门文章