GDB 调试Native Crash 总结

一 、 什么是Native Crash :
最简单的理解就是发生在Native世界里的异常，当然你也可以更直接一些，发生在lib库里异常。
常见的native crash有 SIG 7/11 等，尤其是这两个哥们，在新项目阶段的出场率还是非常高的，访问非法内存/内存对齐诸如此类。
二、如何分析Native Crash：
发生nativeCrash的时候，通常可以从mainlog中看到如下打印：

01-01 08:44:29.559 133 133 I DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

01-01 08:44:29.559 133 133 I DEBUG : Build fingerprint: 'XXXXXXXXXXX:user/release-keys'

01-01 08:44:29.569 133 133 I DEBUG : pid: 261, tid: 326, name: AudioService >>> system_server <<<

01-01 08:44:29.569 133 133 I DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000000d
从这里我们可以看到出现问题的进程和线程分别是261 /326 对应就是system_server / AudioService ，而发生异常的原因就是SIG11 ，访问了一个
非法地址0xd。
那么如何分析呢？我们需要知道出现问题的上下文。
如果您做的是某讯平台，那么在出现问题的时候会将整个内存dump到一个corefile中，同时也会将该进程和线程最后的一段信息以及出现问题的堆栈

dump到tombstone文件中。
接下来就是gdb出场了，这个是gdb调试native crash的第一种方法，也就是离线调试corefile，必要条件是您得有这个版本对应的symbol，通常位于

out /target/product/xx/symbol/ 目录下。
gdb

set solib-search-path symbol/system/lib/
file symbol/system/bin/app_process //如果调试的是应用，均选用app_process，如果是其他的守护进程，请选用其他的binfile。
core core-xxxx-xxx /// corefile的名字。
经过一段时间等待后，corefile就解析完毕了，这个时候就可以进入gdb调试状态了。
常见的命令可以google下，文章很多，我就说下用的最多的几个：
1. bt ，打出当前的调用栈
2. p 打出某个变量的值
3. x/32wx 显示某个地址对应的值 （相当于 *某指针），32wx的参数可以调整，按个人喜好，具体的意思可以google，个人喜欢这个～
4. disass ，显示当前函数的汇编
5. info registers 显示当前的寄存器的值，和上面的返汇编一起使用简直就是必杀技。
6. f x ,切换到某个frame（也就是调用栈的编号，如 f 0 , f 1）
7 . t x ,切换到某个 thread （这个x是gdb给你的编号，不是tid，具体可以info thread 来看）
结合你对此部分代码逻辑的判断，相信就可以定位出问题了。
另外，对于某先必现的问题，我们可以gdb 在线调试，准备工作如下：
1. 你得有symbol
2. 问题手机能够链接上adb

3. 问题手机可以root ， 且有gdbserver(如果没有，可以从prebuilt/android-arm/gdbserver下面找到，然后push到system/bin下面)
4. adb forward tcp:10000 tcp:10000
5. adb shell ps |grep 你想要调试的进程的pid
6. adb shell

gdbserver 127.0.0.1:10000 --attach <pid>
7. gdb

file symbol/system/bin/app_process
set solib-search-path symbol/system/lib/

target remote 127.0.0.1:10000

8 等待 &调试，和离线模式一样，但是更强大，可以打断点，单步等。