今天和大家一起聊聊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