JNI NDK開發Crash錯誤定位 調試

時間  2019-11-30
標籤 jni ndk 開發 crash 錯誤 定位 調試 欄目 系統網絡 简体版
原文   原文鏈接
總結：
搜索backtrace 
而後：
$ /d/android-ndk-r10c/toolchains /arm-linux-androideabi-4.9/prebuilt/windows-x86
_64/bin/arm-linux-androideabi-addr2line .exe -e /e/devel/tools/androidProjects/J
niDemux/app/src/main/obj/local/armeabi-v7a/libjnimedia.so 0006494f
e:\devel\tools\androidProjects\JniDemux\app\src\main/jni/avdemux.c:1207
附：
       在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架構工具鏈目錄結構：
adb shell cat /proc/cpuinfo
Processor       : ARMv7 Processor rev 3 (v7l)
下面經過NDK自帶的例子hello-jni項目來演示一下如何精確的定位錯誤
  1. #include <string.h>
  2. #include <jni.h>
  3. // hell-jni.c
  4. #ifdef __cplusplus
  5. extern "C" {
  6. #endif
  7. void willCrash()
  8. {
  9. int i = 10;
  10. int y = i / 0;
  11. }
  12. JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM* vm, void* reserved)
  13. {
  14. willCrash();
  15. return JNI_VERSION_1_4;
  16. }
  17. jstring
  18. Java_com_example_hellojni_HelloJni_stringFromJNI( JNIEnv* env,
  19. jobject thiz )
  20. {
  21. // 此處省略實現邏輯。。。
  22. }
  23. #ifdef __cplusplus
  24. }
  25. #endif
第7行定義了一個willCrash函數，函數中有一個除0的非法操做，會形成程序崩潰。第13行JNI_OnLoad函數中調用了willCrash，這個函數會在Java加載完.so文件以後回調，也就是說程序一啓動就會崩潰。下面是運行程序後打印的log：
  1. 01-01 17:59:38.246: D/dalvikvm(20794): Late-enabling CheckJNI
  2. 01-01 17:59:38.246: I/ActivityManager(1185):
  3. Start proc com.example.hellojni for activity com.example.hellojni/.HelloJni: pid=20794 uid=10351 gids={50351, 1028, 1015}
  4. 01-01 17:59:38.296: I/dalvikvm(20794): Enabling JNI app bug workarounds for target SDK version 3...
  5. 01-01 17:59:38.366: D/dalvikvm(20794): Trying to load lib /data/app-lib/com.example.hellojni-1/libhello-jni.so 0x422a4f58
  6. 01-01 17:59:38.366: D/dalvikvm(20794): Added shared lib /data/app-lib/com.example.hellojni-1/libhello-jni.so 0x422a4f58
  7. 01-01 17:59:38.366: A/libc(20794): Fatal signal 8 (SIGFPE) at 0x0000513a (code=-6), thread 20794 (xample.hellojni)
  8. 01-01 17:59:38.476: I/DEBUG(253): pid: 20794, tid: 20794, name: xample.hellojni >>> com.example.hellojni <<<
  9. 01-01 17:59:38.476: I/DEBUG(253): signal 8 (SIGFPE), code -6 (SI_TKILL), fault addr 0000513a
  10. 01-01 17:59:38.586: I/DEBUG(253): r0 00000000 r1 0000513a r2 00000008 r3 00000000
  11. 01-01 17:59:38.586: I/DEBUG(253): r4 00000008 r5 0000000d r6 0000513a r7 0000010c
  12. 01-01 17:59:38.586: I/DEBUG(253): r8 75226d08 r9 00000000 sl 417c5c38 fp bedbf134
  13. 01-01 17:59:38.586: I/DEBUG(253): ip 41705910 sp bedbf0f0 lr 4012e169 pc 4013d10c cpsr 000f0010
  14. // 省略部份日誌 。。。。。。
  15. 01-01 17:59:38.596: I/DEBUG(253): backtrace:
  16. 01-01 17:59:38.596: I/DEBUG(253): #00 pc 0002210c /system/lib/libc.so (tgkill+12)
  17. 01-01 17:59:38.596: I/DEBUG(253): #01 pc 00013165 /system/lib/libc.so (pthread_kill+48)
  18. 01-01 17:59:38.596: I/DEBUG(253): #02 pc 00013379 /system/lib/libc.so (raise+10)
  19. 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)
  20. 01-01 17:59:38.596: I/DEBUG(253): #04 pc 00000cf4 /data/app-lib/com.example.hellojni-1/libhello-jni.so (willCrash+32)
  21. 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)
  22. 01-01 17:59:38.596: I/DEBUG(253): #06 pc 00052eb1 /system/lib/libdvm.so (dvmLoadNativeCode(char const*, Object*, char**)+468)
  23. 01-01 17:59:38.596: I/DEBUG(253): #07 pc 0006a62d /system/lib/libdvm.so
  24. 01-01 17:59:38.596: I/DEBUG(253): // 省略部份日誌 。。。。。。
  25. 01-01 17:59:38.596: I/DEBUG(253): stack:
  26. 01-01 17:59:38.596: I/DEBUG(253): bedbf0b0 71b17034 /system/lib/libsechook.so
  27. 01-01 17:59:38.596: I/DEBUG(253): bedbf0b4 7521ce28
  28. 01-01 17:59:38.596: I/DEBUG(253): bedbf0b8 71b17030 /system/lib/libsechook.so
  29. 01-01 17:59:38.596: I/DEBUG(253): bedbf0bc 4012c3cf /system/lib/libc.so (dlfree+50)
  30. 01-01 17:59:38.596: I/DEBUG(253): bedbf0c0 40165000 /system/lib/libc.so
  31. 01-01 17:59:38.596: I/DEBUG(253): // 省略部份日誌 。。。。。。
  32. 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文件和定義的兩個函數，在這裏引起了異常，致使程序崩潰。
  1. 01-01 17:59:38.596: I/DEBUG(253): #04 pc 00000cf4 /data/app-lib/com.example.hellojni-1/libhello-jni.so (willCrash+32)
  2. 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爲例，執行以下命令：
  1. /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。
$ /d/android-ndk-r10c/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86
_64/bin/arm-linux-androideabi-addr2line.exe -e /e/devel/tools/androidProjects/J
niDemux/app/src/main/obj/local/armeabi-v7a/libjnimedia.so 0006494f
e:\devel\tools\androidProjects\JniDemux\app\src\main/jni/avdemux.c:1207
方式2：使用arm-linux-androideabi-objdump  定位出錯的函數信息
在第一種方式中，經過addr2lin已經獲取到了代碼出錯的位置， 可是不知道函數的上下文信息，顯得有點不是那麼的「完美」，對於追求極致的我來講，這顯然是不夠的，下面咱們來看一下怎麼來定位函數的信息。
首先使用以下命令導出so的函數表信息：
  1. /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架構爲例，執行以下命令：
  1. adb logcat | ndk-stack -sym /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a
當程序發生crash時，會輸出以下信息：
  1. pid: 22654, tid: 22654, name: xample.hellojni >>> com.example.hellojni <<<
  2. signal 8 (SIGFPE), code -6 (SI_TKILL), fault addr 0000587e
  3. Stack frame #00 pc 0002210c /system/lib/libc.so (tgkill+12)
  4. Stack frame #01 pc 00013165 /system/lib/libc.so (pthread_kill+48)
  5. Stack frame #02 pc 00013379 /system/lib/libc.so (raise+10)
  6. 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
  7. 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
  8. 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
  9. Stack frame #06 pc 00052eb1 /system/lib/libdvm.so (dvmLoadNativeCode(char const*, Object*, char**)+468)
  10. Stack frame #07 pc 0006a62d /system/lib/libdvm.so
第7行和第8行分別打印出了在源文件中出錯的位置，和addr2line獲得的結果同樣。
先獲取日誌再分析：
這種方式 和上面的方法差很少， 只是獲取log的來源不同。適用於應用或遊戲給測試部們測試的時候，測試人員發現crash，用adb logcat保存日誌文件，而後發給程序員經過ndk-stack命令分析。操做流程以下：
  1. adb logcat > crash.log
  2. ndk-stack -sym /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a -dump crash.log
$ ndk-stack.exe -sym /e/devel/tools/androidProjects/JniDemux/app/src/main/obj/l  ocal/armeabi-v7a/ -dump /e/devel/tools/androidProjects/JniDemux/ccccc.log
會獲得
Stack frame I/DEBUG   (12219):     #04  pc 0000dda7  /system/lib/libc.so (free+1  0) 
Stack frame I/DEBUG   (12219):     #05  pc 00062533  /data/app-lib/com.elesos.jn  idemux-1/libjnimedia.so (start_demux+762): Routine start_demux at e:\devel\tools \androidProjects\JniDemux\app\src\main/jni/avdemux.c:474
獲得的結果和上面的方式是同樣的。
參考
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程