Android Native Error

一、前言

這篇文章咱們來看看 Android Native Error / Crash 的問題在開發時如何調試分析。當然,只要能分析出原因,自然就知道如何去解決啦。


Android Native Error / Crash 開發時調試分析


二、問題分析過程

下面的代碼,在運行時必然發生空指針 NULL 異常,從而 引發 App Native Crash。

<code>char *p = NULL;
char c = *p;
/<code>

本地 / 開發時調試,很明顯就是我們在開發時遇到程序發生的崩潰,或者這是一個可以復現的問題。當然,也假設這個 so 是我們自己的。那麼,這個時候我們的 so 是 unstripped (未剝離版共享庫),簡單來說就是帶有 debug 時的符號表。

下面,我們先來看一下,上面的代碼在發生異常時,其報錯的大致異常 log 會是怎麼樣的。

<code>--------- beginning of crash
02-17 23:05:30.893 2610 2610 F libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 2610 (ly.com.crash)
02-17 23:05:30.998 1297 1297 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
02-17 23:05:30.999 1297 1297 F DEBUG : Build fingerprint: 'Android/sdk_phone_x86_64/generic_x86_64:6.0/MASTER/4174734:userdebug/test-keys'
02-17 23:05:30.999 1297 1297 F DEBUG : Revision: '0'
02-17 23:05:30.999 1297 1297 F DEBUG : ABI: 'x86_64'
02-17 23:05:30.999 1297 1297 F DEBUG : pid: 2610, tid: 2610, name: ly.com.crash >>> ly.com.crash <<<
02-17 23:05:30.999 1297 1297 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
02-17 23:05:31.003 1297 1297 F DEBUG : rax 0000000000000000 rbx 0000000012c53500 rcx 0000000000000000 rdx 000000000000000e
02-17 23:05:31.003 1297 1297 F DEBUG : rsi 00007fffbd76dee7 rdi 00007fffbd76df8f
02-17 23:05:31.003 1297 1297 F DEBUG : r8 0000000070799dd8 r9 0000000071d8c3b0 r10 00007fffbd76db80 r11 00007f722f0b21a0
02-17 23:05:31.003 1297 1297 F DEBUG : r12 0000000000000000 r13 0000000012cba100 r14 0000000012c53500 r15 0000000012c82100
02-17 23:05:31.003 1297 1297 F DEBUG : cs 0000000000000033 ss 000000000000002b
02-17 23:05:31.003 1297 1297 F DEBUG : rip 00007f722f0b21e0 rbp 00007fffbd76dfa0 rsp 00007fffbd76df30 eflags 0000000000010202
02-17 23:05:31.004 1297 1297 F DEBUG :
02-17 23:05:31.004 1297 1297 F DEBUG : backtrace:
02-17 23:05:31.004 1297 1297 F DEBUG : #00 pc 000000000000f1e0 /data/app/ly.com.crash-1/lib/x86_64/libnative-lib.so (Java_ly_com_crash_MainActivity_stringFromJNI+64)

02-17 23:05:31.004 1297 1297 F DEBUG : #01 pc 000000000070ba69 /data/app/ly.com.crash-1/oat/x86_64/base.odex (offset 0x2e2000) (java.lang.String ly.com.crash.MainActivity.stringFromJNI()+157)
02-17 23:05:31.004 1297 1297 F DEBUG : #02 pc 000000000070b950 /data/app/ly.com.crash-1/oat/x86_64/base.odex (offset 0x2e2000) (void ly.com.crash.MainActivity.onCreate(android.os.Bundle)+228)
02-17 23:05:31.004 1297 1297 F DEBUG : #03 pc 00000000734ab4bc /data/dalvik-cache/x86_64/system@[email protected] (offset 0x1ed6000)
02-17 23:05:31.040 1297 1297 F DEBUG :
02-17 23:05:31.040 1297 1297 F DEBUG : Tombstone written to: /data/tombstones/tombstone_00
02-17 23:05:31.040 1297 1297 E DEBUG : AM write failed: Broken pipe

/<code>

這個錯誤堆棧是從 logcat 裡面獲取的,其崩潰信息已經相對完善了。而且其中還有一句告知了更詳細的崩潰日誌被寫入到了 /data/tombstones/tombstone_00。我們可以藉助這個 /data/tombstones/tombstone_00 作更詳盡的分析。

然後,針對這個錯誤。從它的 backtrace 中我們可以看到其異常發生在我們自己的 native-lib.so 中了,發生異常的錯誤棧為:

<code> #00 pc 000000000000f1e0  /data/app/ly.com.crash-2/lib/x86_64/libnative-lib.so (Java_ly_com_crash_MainActivity_stringFromJNI+64)
/<code>

在 Android NDK 中給我們提供了一個工具 ndk-stack ,利用 ndk-stack 就可以輕鬆的將上面的異常棧轉換成可定位到源碼具體位置的可讀性更強的異常棧。

使用 ndk-stack 時,我們除了需要包含出問題時的異常棧的 log 之外,我們還需要通過參數 -sym 來指定一個 unstripped 的 .so。一般在開發時,這個 so 的位置可能如下:

  1. 如果你使用的是 ndk-build 來編譯的話,它可能位於
<code>$PROJECT_PATH/app/build/intermediates/ndk-build/debug/obj/x86_64/***.so

/<code>
  1. 如果使用的是 cmake 來編譯的話,它可能位於
<code>$PROJECT_PATH/app/build/intermediates/cmake/debug/obj/x86_64/***.so
/<code>

而對於指定異常 log 的方式,ndk-stack 也提供了兩種方式:

  1. 將 logcat 直接作為輸入:
<code>adb logcat | ndk-stack -sym $PROJECT_PATH/app/build/intermediates/cmake/debug/obj/x86_64

/<code>
  1. 通過 -dump 指定一個包含異常日誌的文件
<code>ndk-stack -sym $PROJECT_PATH/app/build/intermediates/cmake/debug/obj/x86_64 -dump foo.txt
/<code>

上面的 $PROJECT_PATH 你需要替換成你自己的工程絕對路徑。

就這樣,通過上面一頓猛如虎的操作之後,我們可以得到異常棧轉換後的可讀性更強的棧:

<code>#00 0x000000000000f1e0 /data/app/ly.com.crash-2/lib/x86_64/libnative-lib.so (Java_ly_com_crash_MainActivity_stringFromJNI+64)
Java_ly_com_crash_MainActivity_stringFromJNI
/Users/ly/github/HelloCrash/app/src/main/cpp/native-lib.cpp:10:14
/<code>

可以看到,發生異常的地方在 native-lib.cpp 的 第 10 行第 14 列。

三、總結

針對開發時,所發生的 native crash 來分析還是很簡單的。那麼,當我們的應用打成 release 包之後,發佈線上之後又該如何分析呢?


分享到:


相關文章: