Android Native Crash 收集

今天跟大家讲一下，我最近掉了几百根头发写出来的一个 Native Crash 收集的功能（脱发已经越来越严重了）。

一个 Native Crash 的 log 信息如下图：

这张图是我在网上找的(由于没有写 demo，项目中的截图不方便直接拿出来，就偷了个懒)。

在上图里，堆栈信息中 pc 后面跟的内存地址，就是当前函数的栈地址，我们可以通过命令行arm-linux-androideabi-addr2line -e 内存地址得出出错的代码行数了。

要实现 Native Crash 的收集，主要有四个重点：知道 Crash 的发生；捕获到 Crash 的位置；获取 Crash 发生位置的函数调用栈；数据能回传到服务器。

知道 Crash 的发生

与 Java 平台不同，C/C++ 没有一个通用的异常处理接口，在 C 层，CPU 通过异常中断的方式，触发异常处理流程。不同的处理器，有不同的异常中断类型和中断处理方式，linux 把这些中断处理，统一为信号量，每一种异常都有一个对应的信号，可以注册回调函数进行处理需要关注的信号量。

所有的信号量都定义在<signal.h>文件中，这里我将几乎全部的信号量以及所代表的含义都标注出来了：

#define SIGHUP 1 // 终端连接结束时发出(不管正常或非正常)#define SIGINT 2 // 程序终止(例如 Ctrl-C)#define SIGQUIT 3 // 程序退出(Ctrl-)#define SI

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

GILL 4 // 执行了非法指令，或者试图执行数据段，堆栈溢出 #define SIGTRAP 5 // 断点时产生，由 debugger 使用 #define SIGABRT 6 // 调用 abort 函数生成的信号，表示程序异常 #define SIGIOT 6 // 同上，更全，IO 异常也会发出 #define SIGBUS 7 // 非法地址，包括内存地址对齐出错，比如访问一个 4 字节的整数, 但其地址不是 4 的倍数 #define SIGFPE 8 // 计算错误，比如除 0、溢出 #define SIGKILL 9 // 强制结束程序，具有最高优先级，本信号不能被阻塞、处理和忽略 #define SIGUSR1 10 // 未使用，保留 #define SIGSEGV 11 // 非法内存操作，与 SIGBUS 不同，他是对合法地址的非法访问，比如访问没有读权限的内存，向没有写权限的地址写数据 #define SIGUSR2 12 // 未使用，保留 #define SIGPIPE 13 // 管道破裂，通常在进程间通信产生 #define SIGALRM 14 // 定时信号,#define SIGTERM 15 // 结束程序，类似温和的 SIGKILL，可被阻塞和处理。通常程序如果终止不了，才会尝试 SIGKILL#define SIGSTKFLT 16 // 协处理器堆栈错误 #define SIGCHLD 17 // 子进程结束时, 父进程会收到这个信号。#define SIGCONT 18 // 让一个停止的进程继续执行 #define SIGSTOP 19 // 停止进程,本信号不能被阻塞,处理或忽略 #define SIGTSTP 20 // 停止进程,但该信号可以被处理和忽略 #define SIGTTIN 21 // 当后台作业要从用户终端读数据时, 该作业中的所有进程会收到 SIGTTIN 信号 #define SIGTTOU 22 // 类似于 SIGTTIN, 但在写终端时收到 #define SIGURG 23 // 有紧急数据或 out-of-band 数据到达 socket 时产生 #define SIGXCPU 24 // 超过 CPU 时间资源限制时发出 #define SIGXFSZ 25 // 当进程企图扩大文件以至于超过文件大小资源限制 #define SIGVTALRM 26 // 虚拟时钟信号. 类似于 SIGALRM, 但是计算的是该进程占用的 CPU 时间.#define SIGPROF 27 // 类似于 SIGALRM/SIGVTALRM, 但包括该进程用的 CPU 时间以及系统调用的时间 #define SIGWINCH 28 // 窗口大小改变时发出 #define SIGIO 29 // 文件描述符准备就绪, 可以开始进行输入/输出操作 #define SIGPOLL SIGIO // 同上，别称 #define SIGPWR 30 // 电源异常 #define SIGSYS 31 // 非法的系统调用

通常我们在做 crash 收集的时候，主要关注这几个信号量：

const int signal_array[] = {SIGILL, SIGABRT, SIGBUS, SIGFPE, SIGSEGV, SIGSTKFLT, SIGSYS};

对应的含义可以参考上文，

extern int sigaction(int, const struct sigaction*, struct sigaction*);

第一个参数 int 类型，表示需要关注的信号量

第二个参数 sigaction 结构体指针，用于声明当某个特定信号发生的时候，应该如何处理。

第三个参数也是 sigaction 结构体指针，他表示的是默认处理方式，当我们自定义了信号量处理的时候，用他存储之前默认的处理方式。

这也是指针与引用的区别，指针操作操作的都是变量本身，所以给新指针赋值了以后，需要另一个指针来记录封装了默认处理方式的变量在内存中的位置。

所以，要订阅异常发生的信号，最简单的做法就是直接用一个循环遍历所有要订阅的信号，对每个信号调用sigaction()

void init() {struct sigaction handler;struct sigaction old_signal_handlers[SIGNALS_LEN];for (int i = 0; i < SIGNALS_LEN; ++i) {sigaction(signal_array[i], &handler, & old_signal_handlers[i]);}}

捕获到 Crash 的位置

sigaction 结构体有一个 sa_sigaction变量，他是个函数指针，原型为：void (*)(int siginfo_t *, void *)

因此，我们可以声明一个函数，直接将函数的地址赋值给sa_sigaction

void signal_handle(int code, siginfo_t *si, void *context) {}

void init() {struct sigaction old_signal_handlers[SIGNALS_LEN];

struct sigaction handler;handler.sa_sigaction = signal_handle;handler.sa_flags = SA_SIGINFO;

for (int i = 0; i < SIGNALS_LEN; ++i) {sigaction(signal_array[i], &handler, & old_signal_handlers[i]);}}

这样当发生 Crash 的时候就会回调我们传入的signal_handle()函数了。在signal_handle()函数中，我们得要想办法拿到当前执行的代码信息。

设置紧急栈空间

如果当前函数发生了无限递归造成堆栈溢出，在统计的时候需要考虑到这种情况而新开堆栈否则本来就满了的堆栈又在当前堆栈处理溢出信号，处理肯定是会失败的。所以我们需要设置一个用于紧急处理的新栈，可以使用sigaltstack()在任意线程注册一个可选的栈，保留一下在紧急情况下使用的空间。（系统会在危险情况下把栈指针指向这个地方，使得可以在一个新的栈上运行信号处理函数）

void signal_handle(int sig) {write(2, "stack overflow\n", 15);_exit(1);}unsigned infinite_recursion(unsigned x) {return infinite_recursion(x)+1;}int main() {static char stack[SIGSTKSZ];stack_t ss = {.ss_size = SIGSTKSZ,.ss_sp = stack,};struct sigaction sa = {.sa_handler = signal_handle,.sa_flags = SA_ONSTACK};sigaltstack(&ss, 0);sigfillset(&sa.sa_mask);sigaction(SIGSEGV, &sa, 0);infinite_recursion(0);}

捕获出问题的代码

signal_handle() 函数中的第三个参数 context 是uc_mcontext的结构体指针，它封装了 cpu 相关的上下文，包括当前线程的寄存器信息和奔溃时的 pc 值，能够知道崩溃时的 pc，就能知道崩溃时执行的是那条指令，同样的，在本文顶部的那张图中寄存器快照就可以用如下代码获得。

char *head_cpu = nullptr;asprintf(&head_cpu, "r0 %08lx r1 %08lx r2 %08lx r3 %08lx\n""r4 %08lx r5 %08lx r6 %08lx r7 %08lx\n""r8 %08lx r9 %08lx sl %08lx fp %08lx\n""ip %08lx sp %08lx lr %08lx pc %08lx cpsr %08lx\n",t->uc_mcontext.arm_r0, t->uc_mcontext.arm_r1, t->uc_mcontext.arm_r2,t->uc_mcontext.arm_r3, t->uc_mcontext.arm_r4, t->uc_mcontext.arm_r5,t->uc_mcontext.arm_r6, t->uc_mcontext.arm_r7, t->uc_mcontext.arm_r8,t->uc_mcontext.arm_r9, t->uc_mcontext.arm_r10, t->uc_mcontext.arm_fp,t->uc_mcontext.arm_ip, t->uc_mcontext.arm_sp, t->uc_mcontext.arm_lr,t->uc_mcontext.arm_pc, t->uc_mcontext.arm_cpsr);

不过uc_mcontext结构体的定义是平台相关的，比如我们熟知的arm、x86这种都不是同一个结构体定义，上面的代码只列出了arm架构的寄存器信息，要兼容其他架构的 cpu 在处理的时候，就得要寄出宏编译大法，不同的架构使用不同的定义。

uintptr_t pc_from_ucontext(const ucontext_t *uc) {#if (defined(arm))return uc->uc_mcontext.arm_pc;#elif defined(aarch64)return uc->uc_mcontext.pc;#elif (defined(x86_64))return uc->uc_mcontext.gregs[REG_RIP];#elif (defined(__i386))return uc->uc_mcontext.gregs[REG_EIP];#elif (defined (ppc)) || (defined (powerpc))return uc->uc_mcontext.regs->nip;#elif (defined(hppa))return uc->uc_mcontext.sc_iaoq[0] & ~0x3UL;#elif (defined(sparc) && defined (arch64))return uc->uc_mcontext.mc_gregs[MC_PC];#elif (defined(sparc) && !defined (arch64))return uc->uc_mcontext.gregs[REG_PC];#else#error "Architecture is unknown, please report me!"#endif}

pc 值转内存地址

pc 值是程序加载到内存中的绝对地址，绝对地址不能直接使用，因为每次程序运行创建的内存肯定都不是固定区域的内存，所以绝对地址肯定每次运行都不一致。我们需要拿到崩溃代码相对于当前库的相对偏移地址，这样才能使用 addr2line 分析出是哪一行代码。通过dladdr()可以获得共享库加载到内存的起始地址，和pc值相减就可以获得相对偏移地址，并且可以获得共享库的名字。

Dl_info info;

if (dladdr(addr, &info) && info.dli_fname) {

void * const nearest = info.dli_saddr;

uintptr_t addr_relative = addr - info.dli_fbase;

}

获取 Crash 发生时的函数调用栈

获取函数调用栈是最麻烦的，至今没有一个好用的，全都要做一些大改动。常见的做法有四种：

• 第一种：直接使用系统的<unwind.h>库，可以获取到出错文件与函数名。只不过需要自己解析函数符号，同时经常会捕获到系统错误，需要手动过滤。

• 第二种：在4.1.1以上，5.0以下，使用系统自带的libcorkscrew.so，5.0 开始，系统中没有了libcorkscrew.so，可以自己编译系统源码中的libunwind。libunwind是一个开源库，事实上高版本的安卓源码中就使用了他的优化版替换libcorkscrew。