学习tombstone，signal

三驾马车（CPU，内存和存储设备）中，跑得最慢的就是存储设备了

电脑上，从HDD 到SSD，从SATA SSD到PCIe SSD，硬盘是越来越快；

手机上，从SD卡，到eMMC卡，再到UFS卡，存储卡的速度也是越来越快。现在一般手机配的是eMMC，旗舰高端手机配的是UFS。

那么，什么是UFS？Universal Flash Storage，通用闪存存储。它有两个意思，一是指手机存储接口协议，类似SATA，PCIe/NVMe；二是使用该协议的存储设备。

UFS和eMMC简介与区别

UFS为什么能那么快？

首先，它在数据信号传输上，使用的是差分串行传输。这是UFS快的基础。所有的高速传输总线，如SATA，PCIe，SAS，都是串行差分信号。串行，可以使用更快的时钟（时钟信息可以嵌在数据流中）；差分信号，即用两根信号线上的电平差表示0或者1。与单端信号传输相比，差分信号抗干扰能力强，能提供更宽的带宽（跑得更快）。打个比方，假设用两个信号线上电平差表示0和1，具体来讲，差值大于0，表示1，差值小于0，表示0。如果传输过程中存在干扰，两个线上加了近乎同样大小的干扰电平，两者相减，差值几乎不变，你大爷还是你大爷。但对单端信号传输来说，就很容易受干扰，比如0-1V表示0,1-3V表示1，一个本来是0.8V的电压，加入干扰，变成1.5V，相当于0变成1，数据就出错了，你大妈已经不是你大妈了。抗干扰能力强，因而可以用更快的速度进行数据传输，从而能提供更宽的带宽了。

UFS的前辈是eMMC，使用的是并行数据传输。并行最大的问题是速度上不去，因为一旦时钟上去，干扰就变大，信号完整性无法保证。

UFS支持命令队列，就是主机一下可以发很多个命令下去，然后UFS设备支持并行和乱序执行，谁先完成谁先返回状态。这种命令处理方式叫做异步命令处理。而它的前辈eMMC，是不支持命令队列的，命令一个一个执行，或者一包一包（每个包里面含有若干个命令）执行，前面命令没有执行完成，后面的命令是不能发下去的。这种命令处理方式叫做同步命令处理。

半双工 同步

主机发了一个写命令W1给设备，然后主机把数据写到设备；由于是同步传输模式，命令处理是一个一个处理的，所以在发读命令R2之前，必须等前一个写命令W1完成；同样，在发送写命令W3之前，必须等R2命令完成。

全双工 同步

由于支持命令队列，主机一下可以发若干个命令给设备，如上图，主机一下发了一个写命令W1和读命令R2给设备。

设备可以并行处理这两个命令，由于协议支持全双工操作，主机传输写命令W1的数据给设备的同时，设备也可以把读命令R2的数据返回给主机。后面命令R3，R4，W5…的处理方式类似。

eMMC的时间轴

如果说eMMC是手机中的HDD，那么UFS就是手机中的SSD。

但苹果手机是用NVMe

UFS芯片如下

大小如大拇指手指盖大小。麻雀虽小，五脏俱全。UFS存储芯片内部封装了UFS控制器和闪存阵列，和SSD结构很相似。不过和SSD相比，由于它的容量更小，因此闪存die比较少，闪存的通道数也少。另外，出于功耗和成本考虑，UFS芯片一般是不带DRAM的架构。

DEBUG是计算机排除故障的意思

Tombstone原理分析

一、Tombstone简介

当一个native程序开始执行时，系统会注册一些连接到debuggerd的signal handlers。针对进程出现的不同的异常状态，Linux kernel会发送相应的signal给异常进程，debuggerd捕获这些signal，做出相应处理的同时（一般来说是退出异常进程），在/data/tombstones目录下生成一个tombstone。Tombstone文件以tombstone_XX形式命名，该文件个数上限可以进行设置，当超过上限时则每次覆盖时间最老的文件。Tombstone记录了崩溃的进程的基本信息，堆栈调用信息，内存信息等等。

二、Tombstone生成过程

为了更好地分析tombstone触发的过程，我们可以先了解一下Android中一个进程是如何跑起来的。

一个APP一般是存储在UFS，EMMC之类的存储设备上，当用户去点击图标的时候，操作系统会把这个APP从Flash里面加载到主存当中，通过类似fork()的命令去创建对应的进程。进程创建完毕之后通过类似exec的命令去加载APP的内容，然后由/system/bin/linker程序加载APP所用到的一些共享库。最终跳转到APP程序的入口处执行。

Debuggerd守护进程的初始化同样是在linker中进行的，下面我们首先分析linker部分中是如何去初始化debuggerd的。

1.Debuggerd初始化

Debuggerd是在linker中进行初始化的，我们从linker的起始位置开始进行分析，在/bionic/linker/arch/arm64/begin.S中可以看到，这里调用了__linker_init函数，对linker进行初始化，__linker_init应该要返回可执行程序的开始地址，之后跳转过去执行。

在__linker_init()方法中调用了__linker_init_post_relocation()，__linker_init_post_relocation()初始化linker的全局变量，之后调用linker_main()函数获取可执行程序的开始地址，然后跳转到开始地址继续执行。

可以看到linker_main()函数中对系统环境进行了确认，对系统属性进行了初始化设置，之后调用linker_debuggerd_init()初始化debuggerd。

linker_debuggerd_init()定义了一个callbacks结构体，之后把这个callbacks作为参数传递给debuggerd_init()，继续进行debuggerd的初始化。

在debuggerd_init()中首先把callbacks赋给g_callbacks，之后调用mmap为线程的栈分配空间，然后调用mprotect函数，设置stack对应的内存区的保护属性为可读可写，之后把栈的起始点定义在页末尾并对齐。最后调用debuggerd_register_handlers()去注册一些异常信号，而异常信号的处理函数是debuggerd_signal_handler()。

在debuggerd_register_handlers()函数中注册异常信号，可以通过这个函数看到都有哪些异常信号会被debuggerd捕获。

2.Debuggerd处理异常

当native进程出现了问题，则通过linux内核判断会发生信号，最终信号在被debuggerd捕获之后由debuggerd_signal_handler()函数处理。debuggerd_signal_handler()使用互斥锁pthread_mutex_lock()来保护线程，防止同一时间多个线程处理信号产生冲突。首先调用log_signal_summary()来输出一些信息，调用log_signal_summary()的目的是防止后面动作出错，最终无法定位到是哪个进程出现了错误，所以先在这里打印一些关键信息。可以在logcat里找到对应的信息。在这一部分中打印如下信息：信号的num、信号code、Fault addr出错时的地址、tid：对应的线程id和pid：对应的进程id。

之后debuggerd_signal_handler()调用debuggerd_dispatch_pseudothread()，通过clone系统调用clone出一个伪线程，去处理dispatch信号，原来的线程原地等待子线程的开始和结束。

在伪线程中通过fork去创建子线程，新创建的子线程中通过execle系统调用去执行crash_dump64程序，父进程等待crash_dump64进程退出。

在crash_dump64进程中，再fork出一个新进程，父进程通过fork_exit_read去等待子进程，子进程继续执行crash_dump的任务。

在crash_dump中，通过/proc/PID/cmdline获取进程的名字，通过/proc/PID/fd/获取此进程打开了多少文件，每个文件都有一个文件描述符。

循环遍历这个进程中的所有线程，对进程中的每一个线程进行ptrace操作，对目标线程读取其crashinfo。Crashinfo读取完毕后detach当前的线程。

之后在crash_dump()中调用tombstoned_connect()通过socket连接到tombstone进程。根据signal的si_val的值不同做出不同的判断，为0时dump tombstone，为1时只dump backtrace。

最终tombstone通过engrave_tombstone()函数生成，engrave_tombstone函数的第二个参数，unwinder，是输出 backtrace等信息的关键函数。

通过unwinder的初始化函数我们可以看到，unwinder初始化过程中获取了当前进程的内存和memory map。这些信息会在后面帮助debuggerd生成tombstone文件。

对tombstone的生成过程做一个小结，当Native进程发生了异常，操作系统会去异常向量表的地址去处理异常，然后发送信号。在debuggred_init()注册的信号处理函数就会捕获信号并处理，创建伪线程去启动crash_dump进程，crash_dump则会获取当前进程中各个线程的crash信息。tombstoned进程是开机就启动的，开机时注册好了socket等待连接。当crash_dump()去连接tombstoned进程的时候，根据传递的dump_type类型会返回一个/data/tombstones/下文件描述符。

crash_dump进程后续通过engrave_tombstone函数将所有的线程的详细信息写入到tombstone文件中，至此就在/data/tombstones下生成了此次对应的tombstone_XX文件。

三、Tombstone文件实例分析

上文中我们提到，tombstone通过engrave_tombstone()函数生成，在这一节中，我们将结合实例和代码来介绍tombstone文件中都包含哪些内容，这些内容都是如何获取和输出出来的。实例中的tombstone文件由Google提供的development.apk生成。

engrave_tombstone()中首先调用的是dump_header_info()函数打印tombstone头信息。

可以从tombstone实例中看到dump_header_info()函数输出的是一些和编译，CPU架构相关的信息。

调用dump_time_stamp()打印native crash发生的时间。

Tombstone实例如下，这里打印的时间是本机时间，因为实验机没有联网设置时间所以显示时间是2020-01-01 12:23:27 0800。

然后engrave_tombstone()要打印的是线程相关信息，首先调用unwinder的GetProcessMemory()方法，获取进程对应的内存信息，之后engrave_tombstone()把unwinder和获取到的内存信息作为参数传递给dump_thread()打印线程相关的信息。

dump_thread()中调用的第一个函数是dump_thread_info()，它的职责是打印出错的线程所属的进程pid，线程tid，线程名，进程名和出错线程对应的apk的uid。Tombstone实例如下：

然后dump_thread()调用dump_signal_info()函数打印引发这次tombstone的信号信息，dump_thread()在调用这个函数时把thread_info和进程对应的内存传递给了dump_signal_info()。在dump_signal_info函数中首先调用signal_has_si_addr()对信号的signo进行判断，可以在下面的函数中看到，只有在信号不是manually sent并且是某些特定信号的情况下，才会有对应的si_addr。

Tombstone实例如下，可以看到虽然SIGSEGV信号在上面列出的信号列表中，但是因为si_code是SI_USER，所以还是没有对应的信号地址。

之后调用dump_probable_cause()，通过分析signal_info打印可能的原因信息，主要依靠分析signal number和fault address来得出可能的结论。如果没有分析出可能的原因就不会打印出任何信息，在本文使用的这个tombstone的例子中就没有任何信息输出。

之后调用dump_registers()输出出错时寄存器的值，thread_info里面记录了错误发生时的寄存器信息，dump_registers将他们按顺序输出到tombstone文件里。Tombstone实例如下：

调用log_backtrace()打印backtrace信息，先在unwinder中调用unwind()方法解析内存中的信息，然后log_backtrace函数中调用了unwinder的FormatFrame()函数把获取的堆栈信息输出到tombstone文件中。调用unwinder的unwind()方法会导致保存的寄存器的值发生变化，所以在调用这个方法之前先对寄存器的值做一个备份。

unwind()函数中，首先根据pc寄存器的值找到函数unwind的段内存地址

然后根据unwind段中信息找到指令相关的编码数据，elf表等

接着根据入栈地址，分析函数上一级的栈底保存的sp和lr寄存器的值；最后更新寄存器信息。

在tombstone实例中，依次输出pc寄存器的值，对应的文件名，对应的函数名和offset。最近的frame中的pc寄存器的值可以直接从thread_info当中获取，后面的pc寄存器的值在unwind的过程中更新；后面的文件名可以根据memory map和pc寄存器中的地址得出；后面的function name和function offset是通过memory map和pc寄存器中的地址找到dex文件，解析dex文件可以得到对应的函数名和offset。

接下来调用dump_memroy_and_code()函数，这个函数只在主线程中调用，它循环遍历每一个寄存器，打印寄存器附近的memory信息。dump_memory_and_code()中主要是获取寄存器名和值，还有map_info的name属性编辑到label中，真正进行dump的部分在dump_memory()函数里。dump_memory()函数中从寄存器记录的地址addr的位置读取了256个byte的内存到data中，并输出到Tombstone文件，每16个byte一行，输出了16行，输出的第一段是对应的起始地址，第二第三段是内存的值，每一个byte用两个16进制数表示，第四段是对应的ascii码。

随后调用dump_all_maps()打印map信息，dump_threads()向dump_all_maps()传入unwinder和信号的对应地址，和dump_memroy_and_code()一样，dump_all_maps()只在主线程中被调用。Map信息在unwinder初始化的时候获取，map信息记录了进程对应的内存映射，包括开始地址，长度，访问权限，文件描述符，offset等信息。

从Tombstone实例中可以看到输出的信息依次为内存的起始和结束位置，对内存的操作权限，内存的offset，内存的长度，map的名字和buildID

至此dump_threads()函数运行完成，回到engrave_tombstone()函数中。随后engrave_tombstone()函数调用dump_logs()打印systemlog和mainlog的信息。Tombstone实例如下：

四、Tombstone文件分析方法

在tombstone中我们可以看到进程的pid和线程的tid，如果pid和tid相等，那么可以判断crash发生在这个进程的主线程中，后面的name属性表明了crash进程的名称和它在文件系统中的位置。在tombstone中我们还可以看到程序是因为什么信号导致了Crash以及出现错误的地址。根据这些信息可以初步判断crash的类型。下面列出一些信号的常见发送方和触发条件。

除了上面介绍的信息之外，我们主要要分析的是backtrace信息，我们可以通过addr2line工具去分析backtrace，根据backtrace提供的内存地址和符号库文件去找到代码出错的具体位置。我们可以通过addr2line工具找到是哪个文件下的哪个函数的哪一行发生了crash，在backtrace中越靠上的越接近最后被调用的函数。值得一提的是只有带symbol的so文件才能被定位到。本文中使用的实例中的一些库是在apex文件夹下的，这样的so文件里面是没有symbol的，所以即便找到了对应的so文件，也无法找到对应的代码段。

在可执行程序中都包含有调试信息（编译的时候需要加-g选项），addr2line根据程序源程序的行号和编译后的机器代码之间的对应关系Line Number Table去找找对应的行号。

另一个可以帮助我们解读tombstone文件的是工具是objdump，它可以反汇编指定so文件来得到对应的源代码和汇编代码，objdump工具和addr2line在同一个路径下。