Android NDK開發Crash錯誤定位
來源：程序員人生 發布時間：2015-01-07 08:13:48 閱讀次數：8914次
轉載請注明出處：http://blog.csdn.net/xyang81/article/details/42319789
在Android開發中，程序Crash分3種情況：未捕獲的異常、ANR（Application Not Responding）和閃退（NDK引發毛病）。其中未捕獲的異常根據logcat打印的堆棧信息很容易定位毛病。ANR毛病也好查，Android規定，利用與用戶進行交互時，如果5秒內沒有響利用戶的操作，則會引發ANR毛病，并彈出1個系統提示框，讓用戶選擇繼續等待或立即關閉程序。并會在/data/anr目錄下生成1個traces.txt文件，記錄系統產生anr異常的堆棧和線程信息。如果是閃退，這問題比較難查，通常是項目中用到了NDK引發某類致命的毛病致使閃退。由于NDK是使用C/C++來進行開發，熟習C/C++的程序員都知道，指針和內存管理是最重要也是最容易出問題的地方，稍有不慎就會遇到諸如內存地址訪問毛病、使用野針對、內存泄漏、堆棧溢出、初始化毛病、類型轉換毛病、數字除0等常見的問題，致使最后都是同1個結果：程序崩潰。不會像在Java層產生的異常時彈出“xxx程序無響應，是不是立即關閉”之類的提示框。當產生NDK毛病后，logcat打印出來的那堆日志根據看不懂，更別想從日志當中定位毛病的本源，讓我經常有點抓狂，火冒3丈，喝多少加多寶都不管用。當時嘗試過在各個jni函數中打印日志來跟蹤問題，那效力實在是太低了，而且還定位不到問題。還好老天有眼，讓我找到了NDK提供的幾款調試工具，能夠精確的定位到產生毛病的本源。
NDK安裝包中提供了3個調試工具：addr2line、objdump和ndk-stack，其中ndk-stack放在$NDK_HOME目錄下，與ndk-build同級目錄。addr2line和objdump在ndk的交叉編譯器工具鏈目錄下，下面是我本機NDK交叉編譯器工具鏈的目錄結構：
從上圖的目錄結構中可以看出來，NDK針對不同的CPU架構實現了多套相同的工具。所以在選擇addr2line和objdump工具的時候，要根據你目標機器的CPU架構來選擇。如果是arm架構，選擇arm-linux-androidabi⑷.6/4.8（1般選擇高版本）。x86架構，選擇x86⑷.6/4.8。mipsel架構，選擇mipsel-linux-android⑷.6/4.8。如果不知道目標機器的CPU架構，把手機連上電腦，用adb
shell cat /proc/cpuinfo可以查看手機的CPU信息。下圖是我本機的arm架構工具鏈目錄結構：
下面通過NDK自帶的例子hello-jni項目來演示1下如何精確的定位毛病
#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行定義了1個willCrash函數，函數中有1個除0的非法操作，會造成程序崩潰。第13行JNI_OnLoad函數中調用了willCrash，這個函數會在Java加載完.so文件以后回調，也就是說程序1啟動就會崩潰。下面是運行程序后打印的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⑴/libhello-jni.so 0x422a4f58
01-01 17:59:38.366: D/dalvikvm(20794): Added shared lib /data/app-lib/com.example.hellojni⑴/libhello-jni.so 0x422a4f58
01-01 17:59:38.366: A/libc(20794): Fatal signal 8 (SIGFPE) at 0x0000513a (code=⑹), 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 ⑹ (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⑴/libhello-jni.so (__aeabi_idiv0+8)
01-01 17:59:38.596: I/DEBUG(253): #04 pc 00000cf4 /data/app-lib/com.example.hellojni⑴/libhello-jni.so (willCrash+32)
01-01 17:59:38.596: I/DEBUG(253): #05 pc 00000d1c /data/app-lib/com.example.hellojni⑴/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文件的時候產生了1個致命的毛病，第7行的Fatal signal 8提示這是1個致命的毛病，這個信號是由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⑴/libhello-jni.so (willCrash+32)
01-01 17:59:38.596: I/DEBUG(253): #05 pc 00000d1c /data/app-lib/com.example.hellojni⑴/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⑷.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 定位出錯的函數信息
在第1種方式中，通過addr2lin已獲得到了代碼出錯的位置，但是不知道函數的上下文信息，顯得有點不是那末的“完善”，對尋求極致的我來講，這明顯是不夠的，下面我們來看1下怎樣來定位函數的信息。
首先使用以下命令導出so的函數表信息：
/Users/yangxin/Documents/devToos/java/android-ndk-r9d/toolchains/arm-linux-androideabi⑷.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 ⑹ (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⑴/libhello-jni.so (__aeabi_idiv0+8): Routine __aeabi_idiv0 at /s/ndk-toolchain/src/build/../gcc/gcc⑷.6/libgcc/../gcc/config/arm/lib1funcs.asm:1270
Stack frame #04 pc 00000cf4 /data/app-lib/com.example.hellojni⑴/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⑴/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得到的結果1樣。
先獲得日志再分析：
這類方式和上面的方法差不多，只是獲得log的來源不1樣。適用于利用或游戲給測試部們測試的時候，測試人員發現crash，用adb logcat保存日志文件，然后發給程序員通過ndk-stack命令分析。操作流程以下：
adb logcat > crash.log
adb logcat | ndk-stack -sym /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a -dump crash.log
得到的結果和上面的方式是1樣的。
生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈
