如何定位Android NDK开发中遇到的错误

Posted 2023-04-23

　　只要你细心的查看，再配合Google 提供的工具，完全可以快速地准确定位出错的代码位置，这个工作我们称之为“符号化”。需要注意的是，如果要对NDK错误进行符号化的工作，需要保留编译过程中产生的包含符号表的so文件，这些文件一般保存在$PROJECT_PATH/obj/local/目录下。

　　第一种方法：ndk-stack

　　这个命令行工具包含在NDK工具的安装目录，和ndk-build及其他常用的一些NDK命令放在一起，比如在我的电脑上，其位置是/android-ndk-r9d/ndk-stack。根据Google官方文档，NDK从r6版本开始提供ndk-stack命令，如果你用的之前的版本，建议还是尽快升级至最新的版本。使用ndk –stack命令也有两种方式

　　实时分析日志

　　在运行程序的同时，使用adb获取logcat日志，并通过管道符输出给ndk-stack，同时需要指定包含符号表的so文件位置；如果你的程序包含了多种CPU架构，在这里需求根据错误发生时的手机CPU类型，选择不同的CPU架构目录，如：

　　当崩溃发生时，会得到如下的信息：

　　第二种方法：使用addr2line和objdump命令

　　这个方法适用于那些不满足于上述ndk-stack的简单用法，而喜欢刨根问底的程序员们，这两个方法可以揭示ndk-stack命令的工作原理是什么，尽管用起来稍微麻烦一点，但可以稍稍满足一下程序员的好奇心。

　　先简单说一下这两个命令，在绝大部分的Linux发行版本中都能找到他们，如果你的操作系统是Linux，而你测试手机使用的是Intel x86系列，那么你使用系统中自带的命令就可以了。然而，如果仅仅是这样，那么绝大多数人要绝望了，因为恰恰大部分开发者使用的是Windows，而手机很有可能是armeabi系列。

　　在NDK中自带了适用于各个操作系统和CPU架构的工具链，其中就包含了这两个命令，只不过名字稍有变化，你可以在NDK目录的toolchains目录下找到他们。以我的Mac电脑为例，如果我要找的是适用于armeabi架构的工具，那么他们分别为arm-linux-androideabi-addr2line和arm-linux-androideabi-objdump；位置在下面目录中，后续介绍中将省略此位置：

　　假设你的电脑是Windows系统，CPU架构为mips，那么你要的工具可能包含在一下目录中：

　　接下来就让我们来看看如何使用这两个工具，下面具体介绍。

　　找到日志中的关键函数指针

　　其实很简单，就是找到backtrace信息中，属于我们自己的so文件报错的行。

　　首先要找到backtrace信息，有的手机会明确打印一行backtrace（比如我们这次使用的手机），那么这一行下面的一系列以“#两位数字 pc”开头的行就是backtrace信息了。有时可能有的手机并不会打印一行backtrace，那么只要找到一段以“#两位数字 pc ”开头的行，就可以了。

　　其次要找到属于自己的so文件报错的行，这就比较简单了。找到这些行之后，记下这些行中的函数地址。

参考技术A 　　第一种方法：ndk-stack
　　这个命令行工具包含在NDK工具的安装目录，和ndk-build及其他常用的一些NDK命令放在一起，比如在我的电脑上，其位置是/android-ndk-r9d/ndk-stack。根据Google官方文档，NDK从r6版本开始提供ndk-stack命令，如果你用的之前的版本，建议还是尽快升级至最新的版本。使用ndk –stack命令也有两种方式
　　实时分析日志
　　在运行程序的同时，使用adb获取logcat日志，并通过管道符输出给ndk-stack，同时需要指定包含符号表的so文件位置；如果你的程序包含了多种CPU架构，在这里需求根据错误发生时的手机CPU类型，选择不同的CPU架构目录，如：

　　当崩溃发生时，会得到如下的信息：

　　我们重点看一下#03和#04，这两行都是在我们自己生成的libhello-jni.so中的报错信息，因此会发现如下关键信息：

　　回想一下我们的代码，在JNI_OnLoad()函数中（第61行），我们调用了willCrash()函数；在willCrash()函数中（第69行），我们制造了一个错误。这些信息都被准确无误的提取了出来！是不是非常简单？
　　先获取日志再分析
　　这种方法其实和上面的方法没有什么大的区别，仅仅是logcat日志获取的方式不同。可以在程序运行的过程中将logcat日志保存到一个文件，甚至可以在崩溃发生时，快速的将logcat日志保存起来，然后再进行分析，比上面的方法稍微灵活一点，而且日志可以留待以后继续分析。

　　第二种方法：使用addr2line和objdump命令
　　这个方法适用于那些不满足于上述ndk-stack的简单用法，而喜欢刨根问底的程序员们，这两个方法可以揭示ndk-stack命令的工作原理是什么，尽管用起来稍微麻烦一点，但可以稍稍满足一下程序员的好奇心。
　　先简单说一下这两个命令，在绝大部分的Linux发行版本中都能找到他们，如果你的操作系统是Linux，而你测试手机使用的是Intel x86系列，那么你使用系统中自带的命令就可以了。然而，如果仅仅是这样，那么绝大多数人要绝望了，因为恰恰大部分开发者使用的是Windows，而手机很有可能是armeabi系列。
　　在NDK中自带了适用于各个操作系统和CPU架构的工具链，其中就包含了这两个命令，只不过名字稍有变化，你可以在NDK目录的toolchains目录下找到他们。以我的Mac电脑为例，如果我要找的是适用于armeabi架构的工具，那么他们分别为arm-linux-androideabi-addr2line和arm-linux-androideabi-objdump；位置在下面目录中，后续介绍中将省略此位置：

　　假设你的电脑是Windows系统，CPU架构为mips，那么你要的工具可能包含在一下目录中：

　　接下来就让我们来看看如何使用这两个工具，下面具体介绍。
　　找到日志中的关键函数指针
　　其实很简单，就是找到backtrace信息中，属于我们自己的so文件报错的行。
　　首先要找到backtrace信息，有的手机会明确打印一行backtrace（比如我们这次使用的手机），那么这一行下面的一系列以“#两位数字 pc”开头的行就是backtrace信息了。有时可能有的手机并不会打印一行backtrace，那么只要找到一段以“#两位数字 pc ”开头的行，就可以了。

　　其次要找到属于自己的so文件报错的行，这就比较简单了。找到这些行之后，记下这些行中的函数地址。

　　使用addr2line查找代码位置
　　执行如下的命令，多个指针地址可以在一个命令中带入，以空格隔开即可

　　结果如下：

　　从addr2line的结果就能看到，我们拿到了我们自己的错误代码的调用关系和行数，在hello-jni.cpp的69行和61行（另外两行因为使用的是标准函数，可以忽略掉），结果和ndk-stack是一致的，说明ndk-stack也是通过addr2line来获取代码位置的。

Android NDK开发Crash错误定位

在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

 

 

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

 

 

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

 

 

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

 

 

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

 

 

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

 

 

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

 

 

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

 

 

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  

得到的结果和上面的方式是一样的。

 

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