Android NDK開發Crash錯誤定位

時間 2019-12-04

標籤 android ndk 開發 crash 錯誤定位欄目 Android 简体版

原文原文鏈接

在Android開發中，程序Crash分三種狀況：未捕獲的異常、ANR（Application Not Responding）和閃退（NDK引起錯誤）。其中未捕獲的異常根據logcat打印的堆棧信息很容易定位錯誤。ANR錯誤也好查，Android規定，應用與用戶進行交互時，若是5秒內沒有響應用戶的操做，則會引起ANR錯誤，並彈出一個系統提示框，讓用戶選擇繼續等待或當即關閉程序。並會在/data/anr目錄下生成一個traces.txt文件，記錄系統產生anr異常的堆棧和線程信息。若是是閃退，這問題比較難查，一般是項目中用到了NDK引起某類致命的錯誤致使閃退。由於NDK是使用C/C++來進行開發，熟悉C/C++的程序員都知道，指針和內存管理是最重要也是最容易出問題的地方，稍有不慎就會遇到諸如內存地址訪問錯誤、使用野針對、內存泄露、堆棧溢出、初始化錯誤、類型轉換錯誤、數字除0等常見的問題，致使最後都是同一個結果：程序崩潰。不會像在Java層產生的異常時彈出「xxx程序無響應，是否當即關閉」之類的提示框。當發生NDK錯誤後，logcat打印出來的那堆日誌根據看不懂，更別想從日誌當中定位錯誤的根源，讓我時常有點抓狂，火冒三丈，喝多少加多寶都無論用。當時嘗試過在各個jni函數中打印日誌來跟蹤問題，那效率實在是過低了，並且還定位不到問題。還好老天有眼，讓我找到了NDK提供的幾款調試工具，可以精確的定位到產生錯誤的根源。html

NDK安裝包中提供了三個調試工具：addr2line、objdump和ndk-stack，其中ndk-stack放在$NDK_HOME目錄下，與ndk-build同級目錄。addr2line和objdump在ndk的交叉編譯器工具鏈目錄下，下面是我本機NDK交叉編譯器工具鏈的目錄結構：java

從上圖的目錄結構中能夠看出來，NDK針對不一樣的CPU架構實現了多套相同的工具。因此在選擇addr2line和objdump工具的時候，要根據你目標機器的CPU架構來選擇。若是是arm架構，選擇arm-linux-androidabi-4.6/4.8（通常選擇高版本）。x86架構，選擇x86-4.6/4.8。mipsel架構，選擇mipsel-linux-android-4.6/4.8。若是不知道目標機器的CPU架構，把手機連上電腦，用adb shell cat /proc/cpuinfo能夠查看手機的CPU信息。下圖是我本機的arm架構工具鏈目錄結構：linux

下面經過NDK自帶的例子hello-jni項目來演示一下如何精確的定位錯誤android

[cpp] view plain copygit

#include <string.h>
#include <jni.h>
// hell-jni.c
#ifdef __cplusplus
extern "C" {
#endif
void willCrash()
{
int i = 10;
int y = i / 0;
}
JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM* vm, void* reserved)
{
willCrash();
return JNI_VERSION_1_4;
}
jstring
Java_com_example_hellojni_HelloJni_stringFromJNI( JNIEnv* env,
jobject thiz )
{
// 此處省略實現邏輯。。。
}
#ifdef __cplusplus
}
#endif

第7行定義了一個willCrash函數，函數中有一個除0的非法操做，會形成程序崩潰。第13行JNI_OnLoad函數中調用了willCrash，這個函數會在Java加載完.so文件以後回調，也就是說程序一啓動就會崩潰。下面是運行程序後打印的log：程序員

[cpp] view plain copygithub

01-01 17:59:38.246: D/dalvikvm(20794): Late-enabling CheckJNI
01-01 17:59:38.246: I/ActivityManager(1185):
Start proc com.example.hellojni for activity com.example.hellojni/.HelloJni: pid=20794 uid=10351 gids={50351, 1028, 1015}
01-01 17:59:38.296: I/dalvikvm(20794): Enabling JNI app bug workarounds for target SDK version 3...
01-01 17:59:38.366: D/dalvikvm(20794): Trying to load lib /data/app-lib/com.example.hellojni-1/libhello-jni.so 0x422a4f58
01-01 17:59:38.366: D/dalvikvm(20794): Added shared lib /data/app-lib/com.example.hellojni-1/libhello-jni.so 0x422a4f58
01-01 17:59:38.366: A/libc(20794): Fatal signal 8 (SIGFPE) at 0x0000513a (code=-6), thread 20794 (xample.hellojni)
01-01 17:59:38.476: I/DEBUG(253): pid: 20794, tid: 20794, name: xample.hellojni >>> com.example.hellojni <<<
01-01 17:59:38.476: I/DEBUG(253): signal 8 (SIGFPE), code -6 (SI_TKILL), fault addr 0000513a
01-01 17:59:38.586: I/DEBUG(253): r0 00000000 r1 0000513a r2 00000008 r3 00000000
01-01 17:59:38.586: I/DEBUG(253): r4 00000008 r5 0000000d r6 0000513a r7 0000010c
01-01 17:59:38.586: I/DEBUG(253): r8 75226d08 r9 00000000 sl 417c5c38 fp bedbf134
01-01 17:59:38.586: I/DEBUG(253): ip 41705910 sp bedbf0f0 lr 4012e169 pc 4013d10c cpsr 000f0010
// 省略部份日誌。。。。。。
01-01 17:59:38.596: I/DEBUG(253): backtrace:
01-01 17:59:38.596: I/DEBUG(253): #00 pc 0002210c /system/lib/libc.so (tgkill+12)
01-01 17:59:38.596: I/DEBUG(253): #01 pc 00013165 /system/lib/libc.so (pthread_kill+48)
01-01 17:59:38.596: I/DEBUG(253): #02 pc 00013379 /system/lib/libc.so (raise+10)
01-01 17:59:38.596: I/DEBUG(253): #03 pc 00000e80 /data/app-lib/com.example.hellojni-1/libhello-jni.so (__aeabi_idiv0+8)
01-01 17:59:38.596: I/DEBUG(253): #04 pc 00000cf4 /data/app-lib/com.example.hellojni-1/libhello-jni.so (willCrash+32)
01-01 17:59:38.596: I/DEBUG(253): #05 pc 00000d1c /data/app-lib/com.example.hellojni-1/libhello-jni.so (JNI_OnLoad+20)
01-01 17:59:38.596: I/DEBUG(253): #06 pc 00052eb1 /system/lib/libdvm.so (dvmLoadNativeCode(char const*, Object*, char**)+468)
01-01 17:59:38.596: I/DEBUG(253): #07 pc 0006a62d /system/lib/libdvm.so
01-01 17:59:38.596: I/DEBUG(253): // 省略部份日誌。。。。。。
01-01 17:59:38.596: I/DEBUG(253): stack:
01-01 17:59:38.596: I/DEBUG(253): bedbf0b0 71b17034 /system/lib/libsechook.so
01-01 17:59:38.596: I/DEBUG(253): bedbf0b4 7521ce28
01-01 17:59:38.596: I/DEBUG(253): bedbf0b8 71b17030 /system/lib/libsechook.so
01-01 17:59:38.596: I/DEBUG(253): bedbf0bc 4012c3cf /system/lib/libc.so (dlfree+50)
01-01 17:59:38.596: I/DEBUG(253): bedbf0c0 40165000 /system/lib/libc.so
01-01 17:59:38.596: I/DEBUG(253): // 省略部份日誌。。。。。。
01-01 17:59:38.736: W/ActivityManager(1185): Force finishing activity com.example.hellojni/.HelloJni

日誌分析：shell

第3行開始啓動應用，第5行嘗試加載應用數據目錄下的so，第6行在加載so文件的時候產生了一個致命的錯誤，第7行的Fatal signal 8提示這是一個致命的錯誤，這個信號是由linux內核發出來的，信號8的意思是浮點數運算異常，應該是在willCrash函數中作除0操做所產生的。下面重點看第15行backtrace的日誌，backtrace日誌能夠看做是JNI調用的堆棧信息，以「#兩位數字 pc」開頭的都是backtrace日誌。注意看第20行和21行，是咱們本身編譯的so文件和定義的兩個函數，在這裏引起了異常，致使程序崩潰。數組

[cpp] view plain copy架構

01-01 17:59:38.596: I/DEBUG(253): #04 pc 00000cf4 /data/app-lib/com.example.hellojni-1/libhello-jni.so (willCrash+32)
01-01 17:59:38.596: I/DEBUG(253): #05 pc 00000d1c /data/app-lib/com.example.hellojni-1/libhello-jni.so (JNI_OnLoad+20)

開始有些眉目了，但具體崩在這兩個函數的哪一個位置，咱們是不肯定的，若是函數代碼比較少還好查，若是比較複雜的話，查起來也費勁。這時候就須要靠NDK爲咱們提供的工具來精肯定位了。在這以前，咱們先記錄下讓程序崩潰的彙編指令地址，willCrash：00000cf4，JNI_OnLoad：00000d1c

方式1：使用arm-linux-androideabi-addr2line 定位出錯位置
以arm架構的CPU爲例，執行以下命令：

[cpp] view plain copy

/Users/yangxin/Documents/devToos/java/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-addr2line -e /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a/libhello-jni.so 00000cf4 00000d1c

-e：指定so文件路徑

0000cf4 0000d1c：出錯的彙編指令地址

結果以下：

是否是驚喜的看到咱們想要的結果了，分別在hello-jni.c的10和15行的出的錯，再回去看看hello-jni.c的源碼，15行的Jni_OnLoad函內調用了willCrash函數，第10行作了除0的操做引起的crash。

方式2：使用arm-linux-androideabi-objdump 定位出錯的函數信息

在第一種方式中，經過addr2lin已經獲取到了代碼出錯的位置，可是不知道函數的上下文信息，顯得有點不是那麼的「完美」，對於追求極致的我來講，這顯然是不夠的，下面咱們來看一下怎麼來定位函數的信息。
首先使用以下命令導出so的函數表信息：

[cpp] view plain copy

/Users/yangxin/Documents/devToos/java/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-objdump -S -D /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a/libhello-jni.so > Users/yangxin/Desktop/dump.log

在生成的asm文件中，找出咱們開始定位到的那兩個出錯的彙編指令地址（在文件中搜索cf4或willCrash能夠找到），以下圖所示：

經過這種方式，也能夠查出這兩個出錯的指針地址分別位於哪一個函數中。

方式3：ndk-stack

若是你以爲上面的方法太麻煩的話，ndk-stack能夠幫你減輕操做步聚，直接定位到代碼出錯的位置。

實時分析日誌：

使用adb獲取logcat的日誌，並經過管道輸出給ndk-stack分析，並指定包含符號表的so文件位置。若是程序包含多種CPU架構，須要根據手機的CPU類型，來選擇不一樣的CPU架構目錄。以armv7架構爲例，執行以下命令：

[cpp] view plain copy

adb logcat | ndk-stack -sym /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a

當程序發生crash時，會輸出以下信息：

[cpp] view plain copy

pid: 22654, tid: 22654, name: xample.hellojni >>> com.example.hellojni <<<
signal 8 (SIGFPE), code -6 (SI_TKILL), fault addr 0000587e
Stack frame #00 pc 0002210c /system/lib/libc.so (tgkill+12)
Stack frame #01 pc 00013165 /system/lib/libc.so (pthread_kill+48)
Stack frame #02 pc 00013379 /system/lib/libc.so (raise+10)
Stack frame #03 pc 00000e80 /data/app-lib/com.example.hellojni-1/libhello-jni.so (__aeabi_idiv0+8): Routine __aeabi_idiv0 at /s/ndk-toolchain/src/build/../gcc/gcc-4.6/libgcc/../gcc/config/arm/lib1funcs.asm:1270
Stack frame #04 pc 00000cf4 /data/app-lib/com.example.hellojni-1/libhello-jni.so (willCrash+32): Routine willCrash at /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/jni/hello-jni.c:10
Stack frame #05 pc 00000d1c /data/app-lib/com.example.hellojni-1/libhello-jni.so (JNI_OnLoad+20): Routine JNI_OnLoad at /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/jni/hello-jni.c:15
Stack frame #06 pc 00052eb1 /system/lib/libdvm.so (dvmLoadNativeCode(char const*, Object*, char**)+468)
Stack frame #07 pc 0006a62d /system/lib/libdvm.so

第7行和第8行分別打印出了在源文件中出錯的位置，和addr2line獲得的結果同樣。

先獲取日誌再分析：
這種方式和上面的方法差很少，只是獲取log的來源不同。適用於應用或遊戲給測試部們測試的時候，測試人員發現crash，用adb logcat保存日誌文件，而後發給程序員經過ndk-stack命令分析。操做流程以下：

[cpp] view plain copy

adb logcat > crash.log
ndk-stack -sym /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a -dump crash.log

獲得的結果和上面的方式是同樣的。

==================================

咱們如何把一個java中的String改寫爲c中的char*

連接地址

/**
 *Jstring2CStr 把java中的string 轉化成 c中的char數組.
 *jstring   jstr 要被轉化的java string
 *char*  表明的是字符串數組名稱(字符串數組的首地址)
 */
char*   Jstring2CStr(JNIEnv*   env,   jstring   jstr)
{
     char*   rtn   =   NULL;
     jclass   clsstring   =   (*env)->FindClass(env,"java/lang/String");//尋找 java裏面String.class
     jstring   strencode   =   (*env)->NewStringUTF(env,"GB2312");//建立java字符串 "gb2312"
     jmethodID   mid   =   (*env)->GetMethodID(env,clsstring,   "getBytes",   "(Ljava/lang/String;)[B");//尋找到java String getbytes();
     jbyteArray   barr=   (jbyteArray)(*env)->CallObjectMethod(env,jstr,mid,strencode); // String .getByte("GB2312");
     jsize   alen   =   (*env)->GetArrayLength(env,barr); //獲取長度
     jbyte*   ba   =   (*env)->GetByteArrayElements(env,barr,JNI_FALSE); //jbyteArray轉爲jbyte* 

     if(alen   >   0)
     {
      rtn   =   (char*)malloc(alen+1);         //"\0"
      memcpy(rtn,ba,alen);
      rtn[alen]=0;
     }
     (*env)->ReleaseByteArrayElements(env,barr,ba,0);  //釋放掉
     return rtn;
}