使用?ndk-stack?的時候需要你的?lib?編譯為?debug版的，通常需要下面的修改：

1.?修改?android.mk，增加，為?LOCAL_CFLAGS?增加?-g?選項
2.?修改?application.mk，增加?APP_OPTIM?:=?debug
3.?nkd-build?-B
4.?從?obj/local/armeabi/?下面把包復制到?libs/armeabi/
5.?出現(xiàn)異常后，調(diào)用?adb?logcat?|?ndk-stack?-sym?libs/armeabi/

?

可以在鏈接的時候生成一個mapfile，總覽整個代碼的地址列表： You need to generate a map file. The map file contains the function address and memory locations in your executable. Have your build system modified to generate a map file.From the map file, you can use a text editor and search for addresses. I once wrote a program to find the two symbols bounding a given address. Worked great for environments like yours.For android, I used the following line in the Application.mk or Android.mk (note that LOCAL_LDFLAGS is semi-undocumented in the Android NDK docs). LOCAL_LDFLAGS := -Wl,-Map,app.map

?

http://blog.csdn.net/xyang81/article/details/42319789

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

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

從上圖的目錄結(jié)構(gòu)中可以看出來，NDK針對不同的CPU架構(gòu)實現(xiàn)了多套相同的工具。所以在選擇addr2line 和objdump工具的時候，要根據(jù)你目標機器的CPU架構(gòu)來選擇。如果是arm架構(gòu)，選擇arm-linux-androidabi- 4.6/4.8（一般選擇高版本）。x86架構(gòu)，選擇x86-4.6/4.8。mipsel架構(gòu)，選擇mipsel-linux-android-4.6 /4.8。如果不知道目標機器的CPU架構(gòu)，把手機連上電腦，用adb shell cat /proc/cpuinfo可以查看手機的CPU信息。下圖是我本機的arm架構(gòu)工具鏈目錄結(jié)構(gòu)：

?

下面通過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) { // 此處省略實現(xiàn)邏輯。。。 } #ifdef __cplusplus } #endif

?第7行定義了一個willCrash函數(shù)，函數(shù)中有一個除0的非法操作，會造成程序崩潰。第13行JNI_OnLoad函數(shù)中調(diào)用了willCrash，這個函數(shù)會在Java加載完.so文件之后回調(diào)，也就是說程序一啟動就會崩潰。下面是運行程序后打印的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行嘗試加載應用數(shù)據(jù)目錄下的so，第6行在加載so文件的時候產(chǎn)生了一個致命的錯誤，第7行的Fatal signal 8提示這是一個致命的錯誤，這個信號是由linux內(nèi)核發(fā)出來的，信號8的意思是浮點數(shù)運算異常，應該是在willCrash函數(shù)中做除0操作所產(chǎn)生的。 下面重點看第15行backtrace的日志，backtrace日志可以看作是JNI調(diào)用的堆棧信息，以“#兩位數(shù)字 pc”開頭的都是backtrace日志。注意看第20行和21行，是我們自己編譯的so文件和定義的兩個函數(shù)，在這里引發(fā)了異常，導致程序崩潰。

?

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)

?

開始有些眉目了，但具體崩在這兩個函數(shù)的哪個位置，我們是不確定的，如果函數(shù)代碼比較少還好查，如果比較復雜的話，查起來也費勁。這時候就需要靠NDK為我們提供的工具來精確定位了。在這之前，我們先記錄下讓程序崩潰的匯編指令地址，willCrash：00000cf4，JNI_OnLoad：00000d1c

方式1：使用arm-linux-androideabi-addr2line ?定位出錯位置
以arm架構(gòu)的CPU為例，執(zhí)行如下命令：

/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：出錯的匯編指令地址

結(jié)果如下：

是不是驚喜的看到我們想要的結(jié)果了，分別在hello-jni.c的10和15行的出的錯，再回去看看hello-jni.c的源碼，15行的Jni_OnLoad函內(nèi)調(diào)用了willCrash函數(shù)，第10行做了除0的操作引發(fā)的crash。

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

在第一種方式中，通過addr2lin已經(jīng)獲取到了代碼出錯的位置，但是不知道函數(shù)的上下文信息，顯得有點不是那么的“完美”，對于追求極致的我來說，這顯然是不夠的，下面我們來看一下怎么來定位函數(shù)的信息。
首先使用如下命令導出so的函數(shù)表信息：

/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可以找到），如下圖所示：

通過這種方式，也可以查出這兩個出錯的指針地址分別位于哪個函數(shù)中。

方式3：ndk-stack

如果你覺得上面的方法太麻煩的話，ndk-stack可以幫你減輕操作步聚，直接定位到代碼出錯的位置。

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

?

當程序發(fā)生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得到的結(jié)果一樣。

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??

得到的結(jié)果和上面的方式是一樣的。

總結(jié)

以上是生活随笔為你收集整理的Android NDK开发Crash错误定位[转]的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。