2. 程式人生 > >Android NDK開發Crash錯誤定位

Android NDK開發Crash錯誤定位

阿新 • • 發佈：2019-06-26

在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專案來演示一下如何精確的定位錯誤

[cpp] view plain copy

 在CODE上檢視程式碼片派生到我的程式碼片

  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.   
  13.     JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM* vm, void* reserved)  
  14.     {  
  15.         willCrash();  
  16.         return JNI_VERSION_1_4;  
  17.     }  
  18.   
  19.     jstring  
  20.     Java_com_example_hellojni_HelloJni_stringFromJNI( JNIEnv* env,  
  21.                                                       jobject thiz )  
  22.     {  
  23.     // 此處省略實現邏輯。。。  
  24.     }  
  25.   
  26. #ifdef __cplusplus  
  27. }  
  28. #endif  

第7行定義了一個willCrash函式，函式中有一個除0的非法操作，會造成程式崩潰。第13行JNI_OnLoad函式中呼叫了willCrash，這個函式會在Java載入完.so檔案之後回撥，也就是說程式一啟動就會崩潰。下面是執行程式後列印的log：

[cpp] view plain copy

 在CODE上檢視程式碼片派生到我的程式碼片

  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檔案和定義的兩個函式，在這裡引發了異常，導致程式崩潰。

[cpp] view plain copy

 在CODE上檢視程式碼片派生到我的程式碼片

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

[cpp] view plain copy

 在CODE上檢視程式碼片派生到我的程式碼片

  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。

方式2：使用arm-linux-androideabi-objdump  定位出錯的函式資訊

在第一種方式中，通過addr2lin已經獲取到了程式碼出錯的位置，但是不知道函式的上下文資訊，顯得有點不是那麼的“完美”，對於追求極致的我來說，這顯然是不夠的，下面我們來看一下怎麼來定位函式的資訊。
首先使用如下命令匯出so的函式表資訊：

[cpp] view plain copy

 在CODE上檢視程式碼片派生到我的程式碼片

  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架構為例，執行如下命令：

[cpp] view plain copy

 在CODE上檢視程式碼片派生到我的程式碼片

  1. 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

 在CODE上檢視程式碼片派生到我的程式碼片

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

[cpp] view plain copy

 在CODE上檢視程式碼片派生到我的程式碼片

  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  

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

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

我們如何把一個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;
}

 

 

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

H264 安卓編碼

 

還推薦一個專案，該專案實現了編碼後的資料存為本地.h264檔案，方便分析，本人Fork的git地址： https://github.com/eterrao/MediaCodecEncodeH264.git

原作者git地址： https://github.com/sszhangpengfei/MediaCodecEncodeH264.git

（在此感謝擁有開源共享精神的各位朋友，因為你們我才能在學習和成長的路上少了很多坑！）

實際上MediaCodec的實現步驟基本都大同小異，但是請注意在API20以後編碼器資料處理的機制有所改變，官方給出的建議如下:

連結： developer.android.com/reference/android/medi

相關推薦

Android NDK開發Crash錯誤定位

在Android開發中，程式Crash分三種情況：未捕獲的異常、ANR（Application Not Responding）和閃

android ndk開發crash崩潰定位:

android使用ndk開發crash崩潰定位: 1、法一：使用ndk-stack輸出呼叫堆疊    cd /home/hk/Android-Develop/android-ndk-r12b 將log.txt放在這個目錄    ./ndk-stack -sym

Android NDK開發常見錯誤

JNI 呼叫時，一直報 No implementation found for native 有一個可能是，如果呼叫的是C++的程式碼，必須加extern "C" 【轉】 jni 呼叫c和c++的區別. 1、JNIEnv *env引數的使用 所有JNI介面的第一個引數是JNIEnv *env

使用android studio進行ndk開發時如何定位crash錯誤

使用android studio進行ndk開發時如何定位crash崩潰錯誤 在ndk開發時, jni層的程式碼一旦出現問題, 就會列印如下資訊, 然後直接閃退, 這時候讓人非常抓狂, 只能過在各個jni函式中列印日誌來跟蹤問題，但是效率實在是太低，碰到有多

如何定位Android NDK開發中遇到的錯誤

應部分同學要求，把之前的幾篇文章合成這個一篇 正式開始這個話題之前，先簡單介紹一下什麼是NDK和JNI，部分內容來自網路 Android NDK是什麼，為什麼我們要用NDK？ Android NDK 是在SDK前面又加上了“原生”二字，即Native Developm

Android NDK 開發總結

設置 .text nbsp def runt 編寫 abi 文件的 targe 一.安裝配置環境 1.安裝Android Studio，下載路徑https://developer.android.com/studio/index.html?hl=zh-cn。我下載的是Win

android NDK開發中，用Cygwin調試本地代碼時報錯“Another debug session running,Use --force to kill it”原因及解決的方法

能夠 att cati kill 時報 andro 使用 deb gdb調試 在使用ndk-gdb調試的時候。運行$NDK/ndk-gdb --verbose報錯“Another debug session running,Use --force to kil

Android NDK開發及OpenCV初步學習筆記

-a cep cto strip 鏈接 jni 加載 idt jniexport https://www.jianshu.com/p/c29bb20908da Android NDK開發及OpenCV初步學習筆記 Super_聖代 關註 2017.08.19 00:

Android NDK開發 Android JNI專案建立

本篇文章只介紹android ndk在windows系統的編譯環境配置方法 更新於2015年1月11日 將更加詳細的介紹一個基本的Android Jni專案的建立。 步驟一：下圖是必須的，配置好這一步驟就可以進行Android JNI專案的建立了。 步驟二：新建一個Andr

Android NDK 開發教程三 Hello JNI 示例

分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow 也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！        

Android相機啟動crash錯誤排查

一個Android的用到相機的service程式，在比較少的情況下會出現在系統啟動時crash。log顯示是在呼叫ACameraDevice_createCaptureSession時返回錯誤ACAMERA_ERROR_STREAM_CONFIGURE_FAIL（這個程式是用jni操作相機的），configu

Android NDK開發（一）CMake構建工具使用

  一、Android studio中需要的外掛：   　　CMake   　　LLDB   　　NDK   二、專案配置 　　 　　①build.gardle的配置  ：多了兩個externalNativeBuild ：def

ubuntu14.04搭建Android-NDK開發環境

1.建立Android平臺工作空間 mkdir AndroidWorkSpace 2.進入Android平臺工作空間，建立NDK工具目錄 cd AndroidWorkSpace mkdir NDK_Tools 3.獲取android-ndk-r10b 下載：wget ht

Android NDK開發之引入第三方庫

在Android開發中我們經常要把一些比較看重安全或者計算效率的東西通過JNI呼叫C/C++程式碼來實現，如果需要實現的功能簡單或者你的C/C++程式碼能力比較強，但是目前還是有很多功能強大的第三方庫的，比如openssl、FFmpeg等，呼叫這些第三方實現顯然比重複造輪子實際的多。 本教程適合將原始的動態

Android NDK開發掃盲及最新CMake的編譯使用

本篇文章旨在簡介 Android 中 NDK 是什麼以及重點講解最新 Android Studio 編譯工具 CMake 的使用 1 NDK 簡介 在介紹 NDK 之前還是首推 Android 官方 NDK 文件。傳送門 官方文件分別從以下幾個方面介紹了 NDK ND

android NDK 開發(2)

java向native層傳遞引數 1.傳遞基本型別引數，可以直接使用 //Java層定義介面 public native static int sum(int a, int b); //.c檔案native層實現 JNIEXPORT jint JNICALL Java_c

android NDK 開發(3)

1.native層呼叫java層static方法 //java層定義方法 public native static void request(); //native層執行完request後回撥此方法 public static void nativeCallBack()

Android NDK開發之旅(6)：JNI函式完全解析與專案實戰

對於基本型別而言，JNI與Java之間的對映是一對一的，比如Java中的int型別直接對應於C/C++中的jint；而對引用型別的處理卻是不同的，JNI把Java中的物件當作一個C指標傳遞到本地函式中，這個指標指向JVM中的內部資料結構，而內部資料結構在記憶體

Android NDK開發之CMake

知之為知之,不知為不知 哇!(先來個王者之哇助助興),最近的專案一直用到Android NDK,簡直頭皮發麻,每次底層出現問題,都要找同事幫忙,甚是尷尬,於是看一些帖子,稍微整理了一下,做個小筆記,同時也分享一下前人之經驗.不說了,開始進入正題. Android開發環境 工具:And

Android NDK開發入門

  接觸Android有一段時間了，NDK算是一道坎，因為對c語言不熟悉，所以也沒怎麼去接觸這一塊，但是最近的學習，越發的覺得，如果想讓app能有更高的效率，比如在影象的處理方面，遊戲開發方面，甚至於要做一些涉及系統層面的操作時，不可避免的要去用到NDK。通過利