前兩者主要是查看當前的進程或者系統框架層的狀態和堆棧就基本可以分析出來，本文主要討論壹下tombstone的情況。
tombstone壹般是由Dalvik錯誤、狀態監視調試器、C層代碼以及libc的壹些問題導致的。
當系統發生tombstone的時候，kernel首先會上報壹個嚴重的警告信號（signal）,上層接收到之後，進程的調試工具會把進程中當時的調用棧現場保存起來，並在系統創建了data/tombstones目錄後把異常時的進程信息寫在此目錄裏面，開發者需要通過調用棧來分析整個調用流程來找出出問題的點。
基本工具：
prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin
在分析的時候仔細讀取匯編會獲得更多有用的異常發生時的信息。
1.arm-eabi-addr2line 將類似libxxx.so 0x00012345的調用棧16進制值翻譯成文件名和函數名
arm-eabi-addr2line -e libxxx.so 0x00012345
2.arm-eabi-nm 列出文件的符號信息
arm-eabi-nm -l -C -n -S libdvm.so > dvm.data
3.arm-eabi-objdump 列出文件的詳細信息
arm-eabi-objdump -C -d libc.so > libc.s
通過以上工具的分析 ，我們可以得到較完整的調用棧以及調用邏輯的匯編碼。
然後需要結合ARM架構及ARM匯編的知識（有些情況下可能需要使用gdb）
來分析出現tombstone的原因，以下是本人遇到過的壹些tombstone的情況：
1.無效的函數指針：指針為NULL或者已經被重新賦值
2.strlen崩潰：導致不完全的棧信息，棧被破壞
3.FILE操作：因為stdio並非線程安全的，多線程操作時，容易出現異常。
本文涉及到的tombstone處理的主要邏輯所在文件如下：
BootReceiver.java -- frameworks\base\services\java\com\android\server
Debuggerd.c -- system\core\debuggerd
ThreadLocal.java -- libcore\luni\src\main\java\java\lang