今天和大家一起聊聊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跨进程通信——signal
https://www.jianshu.com/p/73c33648ffc8
signal 6 (SIGABRT) log分析
https://blog.csdn.net/weixin_29172201/article/details/117613032