[Debug]Native Exception学习（二）

来源：互联网发布：怎么样测试淘宝标题编辑：程序博客网时间：2024/06/07 00:04

1，android debuggerd学习

android debuggerd进程位于bionic/linker/debugger.c文件，system/core/debugger/目录下。

android user thread发生异常的过程，第一步，发生异常的thread被kernel扑捉到，kernel跳转到ARM的异常向量表，即0XFFFF0000位置（4G空间的最后一M），arm从user mode切换到abort mode，最终跳转到kernel里的异常处理函数，此时kernel根据异常类型发送信号给user thread,user thread在信号处理函数里通知debugged进程，debugged收到信号后用ptrace attach userthread并继续执行，并将信号处理恢复默认，此时userthread继续执行又发生异常，此时kernel手到异常直接发送信号给debugged进程，debugged进程用ptrace打印tombstone和log，最后保存coredump信息。

kernel给用户空间发送信号的时候，正常我们应用程序没有注册信号处理函数，那么如何接收kernel的信号处理函数了？

答：android上用户空间的执行，正常都是由/system/bin/linker来将应用程序所需要的动态库加载进进场的地址空间，linker的代码位于/bionic/linker/linker.c，在该文件里的__linker_init()函数里会首先调用debugger_init()函数，而在debugger_init()函数里注册信号处理函数。

用户空间应用程序执行的过程：

Kernel/fs/exec.c（do_execve()）---->serach_binary_handler()------->binfmt_elf.c（load_elf_binary()）----->load_elf_interp()

ptrace介绍：

ptrace介绍

ptrace详细解释

2, Linux tombstone实例学习

http://blog.csdn.net/helldevil/article/details/6682211

Build fingerprint: 'XXXXXXXXX'

pid: 1658, tid: 13086 >>> system_server <<<

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 64696f7e

r0 00000000 r1 00000001 r2 ad12d1e8 r3 7373654d

r4 64696f72 r5 00000406 r6 00974130 r7 40d14008

r8 4b857b88 r9 4685adb4 10 00974130 fp 4b857ed8

ip 00000000 sp 4b857b50 lr afd11108 pc ad115ebc cpsr 20000030

d0 4040000040000000 d1 0000004200000003

d2 4e72cd924285e370 d3 00e81fe04b1b64d8

d4 3fbc71c7009b64d8 d5 3fe999999999999a

d6 4010000000000000 d7 4000000000000000

d8 4000000000000000 d9 0000000000000000

d10 0000000000000000 d11 0000000000000000

d12 0000000000000000 d13 0000000000000000

d14 0000000000000000 d15 0000000000000000

scr 80000012

#00 pc 000108d8 /system/lib/libc.so

#01 pc 0003724c /system/lib/libxvi020.so

#02 pc 0000ce02 /system/lib/libxvi020.so

#03 pc 0000d672 /system/lib/libxvi020.so

#04 pc 00010cce /system/lib/libxvi020.so

#05 pc 00004432 /system/lib/libwimax_jni.so

#06 pc 00011e74 /system/lib/libdvm.so

#07 pc 0004354a /system/lib/libdvm.so

#08 pc 00017088 /system/lib/libdvm.so

#09 pc 0001c210 /system/lib/libdvm.so

#10 pc 0001b0f8 /system/lib/libdvm.so

#11 pc 00059c24 /system/lib/libdvm.so

#12 pc 00059e3c /system/lib/libdvm.so

#13 pc 0004e19e /system/lib/libdvm.so

#14 pc 00011b94 /system/lib/libc.so

#15 pc 0001173c /system/lib/libc.so

code around pc:

ad115e9c 4620eddc bf00bd70 0001736e 0001734e

ad115eac 4605b570 447c4c0a f7f44620 e006edc8

ad115ebc 42ab68e3 68a0d103 f7f42122 6864edd2

ad115ecc d1f52c00 44784803 edbef7f4 bf00bd70

ad115edc 00017332 00017312 2100b51f 46682210

code around lr:

afd110e8 e2166903 1a000018 e5945000 e1a02004

afd110f8 e2055a02 e1a00005 e3851001 ebffed92

afd11108 e3500000 13856002 1a000001 ea000009

afd11118 ebfffe50 e1a01004 e1a00006 ebffed92

afd11128 e1a01005 e1550000 e1a02006 e3a03000

stack:

4b857b10 40e43be8

4b857b14 00857280

4b857b18 00000000

4b857b1c 034e8968

4b857b20 ad118ce9 /system/lib/libnativehelper.so

4b857b24 00000002

4b857b28 00000406

红色的字体：是让我们确认问题到底发生在那个线程中，是主线程还是子线程，这个的判断依据是:如果PID和TID相同，那么问题出在父亲这边。如果PID和TID不相同，那么您悲剧了，问题出在子线程中。

蓝色的字体：应该从下往上看，

addr2line -e -f libc.so 0001173c

然后用objdump命令查看对应地址对应的汇编代码，然后对应上响应的C语言代码，

objdump -S -D libc.so > deassmble_libc.txt

0 0