Android中較容易出現如下三類問題:Force close / ANR / Tombstone java
前二者主要是查看當前的進程或者系統框架層的狀態和堆棧就基本能夠分析出來,本文主要討論一下tombstone的狀況。 linux
tombstone通常是由Dalvik錯誤、狀態監視調試器、C層代碼以及libc的一些問題致使的。 android
當系統發生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 列出文件的符號信息 ui
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