Android教程網
  1. 首頁
  2. Android 技術
  3. Android 手機
  4. Android 系統教程
  5. Android 游戲
 Android教程網 >> Android技術 >> Android資訊 >> Android NDK開發Crash錯誤定位

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提供的幾款調試工具,能夠精確的定位到產生錯誤的根源。

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

從上圖的目錄結構中可以看出來,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架構工具鏈目錄結構:

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

#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:

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

日志分析:

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

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為例,執行如下命令:

/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的函數表信息:

/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架構為例,執行如下命令:

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

當程序發生crash時,會輸出如下信息:

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命令分析。操作流程如下:

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

得到的結果和上面的方式是一樣的。

  1. 上一頁:
  2. 下一頁:
熱門文章
閱讀排行版
Copyright © Android教程網 All Rights Reserved