1.Android NDK Tombstone/Crash 分析

Android NDK Tombstone/Crash 分析

       程序员在调试Bug的源码过程中，访问非法内存是分析最让人头疼的问题。调试程序Bug通常有三种方法：那么如何调试引发Crash的源码NDK程序呢？

       幸运的是，Google早已预见到我们编写的分析NDK代码可能存在缺陷。当NDK程序发生Crash时，源码会在/data/tombstones/路径下生成记录Crash信息的分析绿豆指标公式源码文件tombstone_xx。同时，源码Google在NDK包中也提供了一系列调试工具，分析如addr2line、源码objdump、分析ndk-stack。源码

       在介绍Tombstone之前，分析我们先补充一下Linux信号机制的源码asp身份查询源码相关知识。信号机制是分析Linux进程间通信的一种重要方式，用于正常的源码进程间通信和同步，以及监控系统异常及中断。当应用程序运行异常时，Linux内核会产生错误信号并通知当前进程。当前进程在接收到该错误信号后，python 源码 如何打包可以有三种不同的处理方式。

       当Linux应用程序在执行时发生严重错误，一般会导致程序crash。Linux专门提供了一类crash信号，程序接收到此类信号时，缺省操作是活动报名预约源码将crash的现场信息记录到core文件，然后终止进程。

       什么是Tombstone？Android Native程序本质上就是一个Linux程序，当它在执行时发生严重错误，也会导致程序crash，然后产生一个记录crash的现场信息的文件，在Android系统中就是winform源码在哪下载tombstone文件。

       Tombstone文件位于路径/data/tombstones/下，它记录了死亡进程的基本信息、死亡的地址以及死亡时的现场信息。

       分析出现Crash的原因和代码位置最重要的就是分析这个tombstone文件。tombstone文件主要由以下几部分组成：Build fingerprint、Crashed process and PIDs、Terminated signal and fault address、CPU registers、Call stack、Stack content of each call。

       Crashed process and PIDs信息表示Crash掉进程的基本信息，包括进程号、线程号等。Terminated signal and fault address信息表示程序因为什么信号导致了Crash以及出现错误的地址。Call Stack信息记录了程序在Crash前的函数调用关系以及当前正在执行函数的信息。

       在分析tombstone文件时，我们主要关注Crashed process and PIDs、Terminated signal and fault address和Call stack部分。

       addr2line是NDK中用来获得指定动态链接库文件或者可执行文件中指定地址对应的源代码信息的工具。ndk-stack能自动分析tombstone文件，将崩溃时的调用内存地址和C++代码一行一行对应起来。

       总结来说，Android NDK程序的系统调试并不复杂，只要掌握了正确的方法，了解Tombstone文件中关键信息的含义，学会使用addr2line和ndk_stack这两个超级方便的工具，就可以快速定位到导致NDK程序Crash的Bug。但具体的Bug还需要进一步根据业务逻辑来分析代码。