文章讲述了在Android系统中遇到的Tombstone问题，这是由Dalvik错误、C层代码问题等引起的。作者分析了两种情况：pid与tid相同的问题通常发生在主线程，而pid与tid不同的问题可能涉及系统服务进程。通过信号量分析和日志对比，可以定位问题源头，但过程可能复杂。文章提供了相关链接以供进一步学习。
今天和大家一起聊聊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.youkuaiyun.com/weixin_29172201/article/details/117613032
扫一扫
1692
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
