今天和大家一起聊聊android 中出现的 Tombstone问题，近期在定制pad 上分析设备概率性重启，导出bugreport日志后，除了看到anr log外，同级目录下还看到了tombstones

并且对比以往日志，发现都生产了大量tombstone...,于是决定一探究竟，或许问题和它有关呢 

tombstone概念
tombstone一般是由Dalvik错误、状态监视调试器、C层代码以及libc的一些问题导致的。
当系统发生tombstone的时候，kernel首先会上报一个严重的警告信号(signal),上层接收到之后，进程的调试工具会把进程中当时的调用栈现场保存起来，并在系统创建了data/tombstones目录后把异常时的进程信息写在此目录里面，开发者需要通过调用栈来分析整个调用流程来找出出问题的点。

分析tombstone原因
下面是我遇到的tombstone情况

pid与tid 相同，问题出在主线程

pid与tid 不同，问题出在子线程

 signal 信号量分析

信号机制是进程之间相互传递消息的一种方法，常见的型号种类如下：

 

问题总结
以上两种情况是我遇到的，pid 和tid相同的情况，根据日志分析和对比前后复现问题的tombstone，发现均为三方应用或内部应用在某种场景下诱发Native Crash 
可以根据进程号跟踪到相应位置，（真正找到问题根源可能麻烦些，大体是这个路子）；
pid 和tid不同的情况，分析起来有点无从下手，但是前前后后对比日志，发现这种情况进程均为系统服务进程pid: 467, tid: 806, name: HwBinder:467_3  >>>/vendor/bin/hw/android.hardware.audio.service.mediatek <<<
只能根据signal 来找到比较完整的调用栈以及调用底层编码逻辑...

就简单写到这里了，欢迎大家交流补充，如有不对，敬请纠正!

参考链接
Android Tombstone crash定位分析
https://cloud.tencent.com/developer/article/1969660

Android开发太难了，Native Crash的一切！

android跨进程通信——signal 
https://www.jianshu.com/p/73c33648ffc8
signal 6 (SIGABRT) log分析
https://blog.csdn.net/weixin_29172201/article/details/117613032