Android内存异常机制(用户空间)_NE

常见的Android稳定性异常，有内核异常和Android层异常。内核异常也就是常说的“kernel panic”，简称KE异常；Android层异常又分为java层crash和Native层crash，简称JE、NE异常。

上篇文章介绍了JE异常的抓取机制和处理方式，本文再讲一下NE异常。

Native exception

Android中，出于运行性能、代码安全或者跨平台实现等方面的需要，存在很多调用c、c++代码库的情况。这些库在运行时发生的异常统称native exception。

Android是基于Linux开发的，所以所有的native程序，本质上也是一个linux小程.序，在执行异常的时候，系统会处理相应的信号，然后产生一个tombstone文件, tombstone英文的本意是墓碑，会记录进程死亡时的进程号、线程号、死亡地址、死亡现场(堆栈)。

1.异常抓取机制

Native异常发生的时候，CPU通过中断的形式触发异常处理流程。Linux kernel将会处理中断，统一成信号发送，应用进程注册和处理信号。

所有的so都需要通过linker加载，Android上，linker会默认注册信号处理函数，代码位置在bionic/linker/linker_main.cpp，实现的地方在debuggerd_init()中。

通过sigaction方法，注册接收的信号有：SIGABRT，SIGBUS，SIGFPE，SIGILL，SIGSEGV，SIGSTKFLT，SIGSYS，SIGTRAP，DEBUGGER_SIGNAL，共计9个信号。

接下来，当native exception发生时，处理流程如下：

(1) 应用的默认信号处理函数

debuggerd_signal_handler被调用，执行线程是出问题前线程。其主要作用有2个：

一是调用log_signal_summary方法，打印一条基本的异常信息；

二是执行clone方法，创建子进程，然后debuggerd_dispatch_pseudothread方法会被调用（注意：debuggerd_dispatch_pseudothread方法执行时pid，tid不变。

log_signal_summary方法会在日志中打印一条“Fatal signal”的异常信息。通过注释大致了解，如果后续过程失败，至少先保留一条基本的Native异常信息。例如：

06-04 14:40:46.182 10762 2963 2992 F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x74 in tid 2992 (test), pid 8745 (com.nativeexception.test)

(2) 子进程clone出后，会执行debuggerd_dispatch_pseudothread方法，其主要作用是通过execle函数，执行/system/bin/crash_dump32或/system/bin/crash_dump64程序，并传入相关参数，包括：

• main_tid：发生Native Crash的线程id（目标进程）
• pseudothread_tid：这个不太确定是什么用处。
• debuggerd_dump_type：共有4种dump类型，发生Native Crash时传入的类型是kDebuggerdTombstone

(3) /system/bin/crash_dump64的main方法会执行，代码位置：system/core/debuggerd/crash_dump.cpp，这里可以说是Native Crash异常处理的核心代码，其主要作用是：

解析传入的参数，包括tid、目标进程名，并调用getProcessTids方法获取目标进程的所有线程id集合。

通过ptrace读取应用的寄存器信息，最终汇总所有的异常信息，包括机型版本、abi、信号、寄存器、backtrace等，输出到log中。

Crash_dump进程会fork出一个新进程，父进程通过read去等待子进程的结果，而子进程继续执行crash_dump的任务。

Ptrace循环遍历读取这个进程中的所有线程，对每个线程读取crashinfo、寄存器信息，并保存在thread_info数组中。

(4) 通过Socket通知tombstoned进程（系统常驻进程），传输异常信息，由tombstoned进程将所有异常信息输出到/data/tombstones/tombstone_xx文件中。

这里，android P之前，crash_dumper会直接把文件保存在data/tombstones/目录下，命名为tombstone_xx，从P开始，crash_dumper会先把日志文件输出为一个#9a16b7命名的文件，tombstoned收到通知后再重命名保存为对应的文件

(5) 连接tombstoned后，crash_dump端会通过output_fd将要写入的日志内容通知给tombstoned，tombstoned最终存为文件。

• Dump_head_info用来输出Header信息，分别从ro.build.fingerprint、ro.version、ABI_STRING中读取。
• Dump_timestamp用来输出问题发生的时间。
• Dump_thread则用来打印寄存器信息、backtrace、stack、map信息。从Android Q开始，谷歌封装了一个libunwindstack库集成化接口供crash_dumper来读取这些信息。

这里会打印出tombstone文件的各种关键信息，包含register、memorymap、stack栈等。这个信息都是从unwinder类中获取到的。那么它是在什么时候得到的这些信息？

从函数结构可以看到这个unwinder变量是函数调用传递进来的，一层层往上回溯，最终回到crash_dumper调用engrave_tombstone之前，有这么一句

虽然只有短短的一句init，但是其中已经完成了map、processMemory的获取。

Unwinder变量最终保存了我们需要的所有信息。在Android P之前这一块代码是散落在tombstone.cpp中的，可以看到谷歌在不断的优化代码。

dump_probable_cause是针对特定的段错误信号等，根据信号地址初步推断可能属于哪一类异常，例如“null pointer dereference”。只有这些特定的分类会有打印，其他情况下，cause为empty的时候，是没有这句打印的。

Dump_register用来打印进程的寄存器信息，寄存器信息在前面crash_dump用ptrace获取thread_info，readCrashInfo的时候已经获取到。

接下来，寄存器会拷贝赋值给unwinder变量，然后执行unwinder->Unwind()。然后打印进程的backtrace和stack。

Unwinder->Unwind()函数会根据寄存器pc、sp指针，以及线程maps信息，得到每一层函数栈的map信息、函数名称，最终封装成一个frameData信息，保存在一个名叫frames_的vector数组中。

根据寄存器信息列表里面的pc指针信息，从maps中找到对应的map_info，进而结合process_memory_得到elf info。

填充framedata信息，然后从elf获取对应的函数名称，如果获取失败，赋值为空字符串。

FillInFrame会扩充frames_数组大小，将新的frame信息(起止地址、flag、sp、pc信息等)赋值后保存在数组中。后续得到functionName后再更新进来。frames_对size大小有限制，不可以无限填充。

unwind()函数执行完之后，log_backtrace打印堆栈信息。Log_backtrace会对每个frame调用FormatFrame输出标准信息，包含序号、pc指针、map信息、函数名称和偏移量、buildid。这些信息输出的来源就是刚才unwind()函数中初始化起来的frames_信息。

最终输出的就是tombstone文件中的backtrace部分。如下图

接下来dump_stack。Unwind之后，每个frame中也存储了堆栈指针sp。利用sp信息，可以将当前frame到下一个frame之间的sp指针偏移量运算出来，再从process_memory信息中找到sp对应的栈内容信息，打印到日志中。每个frame最多打印16行，超出的不再打印。

获取栈内容时，如果从map信息中能得到该栈对应的functionName，也会输出到对应stack的行尾。

最终dump出来的内容如下：

然后，如果是主线程，还会加上各寄存器的memory信息，和整个process的maps信息。

输出的内容如下：

到这里，NE异常的信息基本上dump结束。

(6) 接下来，通过Socket通知System_server进程，（NativeCrashListener线程会监听socket通信），并最终调用到AMS#handleApplicationCrashInner方法（逻辑同Java Crash的处理此时保持一致）

上图是相关代码。

(7) AMS收到通知后，会调用handleApplicationCrashInner方法，后面的处理方式和java exception就是一致的了，是弹框、红屏或者是直接闪退，根据系统的配置来做相应的处理。

2.NE异常打印的信息

下图是常见的NE异常tombstone文件内容。

Tombstone的文件内容从上到下依次是fingerprint、revision、ABI信息、timestamp时间戳、主线程的详细信息（singal、tid、processname、寄存器信息、backtrace、stack，以及memory、maps信息）。另外，如果进程有子线程的话，还会打印各个子线程的详细信息。

3.分析方法

常见的tombstone文件内容。

Native exception产生的内容相对较少，没有java堆栈那么清晰。

通常情况下，如果能从堆栈的栈顶直接看到出现异常的函数名，基本上都可以直接定位解决问题。有些时候，堆栈无法看到函数调用信息，这种情况下，需要找到对应版本带符号的so，用最上层出错的pc指针，再用addr2line去解析定位出错的函数。

Addr2line的方法大家可以去网上找一下，很多资料。

这里，Addr2line的工具获取方法和带符号表的so获取方法如下：

安装了NDK之后，Addr2line工具位于sdk\ndk-bundle\toolchains\arm-linux-androideabi-4.9\ prebuilt\windows-x86_64\bin。

带符号的so，如果开发者是系统工程编译的话，一般位于out/target/product/**/symbols/ system/lib下面。如果是基于Android Studio单独开发的应用，一般位于app\src\main\obj\local\\下面，通常带符号的so会比不带的so大很多。