如何調試分析Android中發生的tombstone

http://www.eoeandroid.com/thread-206358-1-1.html?_dsign=7632cd76
如何調試分析Android中發生的tombstone

Android中較容易出現以下三類問題:Force close / ANR / Tombstone

前兩者主要是查看當前的進程或者系統框架層的狀態和堆棧就基本可以分析出來,本文主要討論一下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
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章