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

应部分同学要求，把之前的几篇文章合成这个一篇大笑

正式开始这个话题之前，先简单介绍一下什么是NDK和JNI，部分内容来自网络

view plaincopy  
  1. *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***  
  2.  Build fingerprint: 'vivo/bbk89_cmcc_jb2/bbk89_cmcc_jb2:4.2.1/JOP40D/1372668680:user/test-keys'  
  3.  pid: 32607, tid: 32607, name: xample.hellojni  >>> com.example.hellojni <<<  
  4.  signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000  
  5.      r0 00000000  r1 beb123a8  r2 80808080  r3 00000000  
  6.      r4 5d635f68  r5 5cdc3198  r6 41efcb18  r7 5d62df44  
  7.      r8 4121b0c0  r9 00000001  sl 00000000  fp beb1238c  
  8.      ip 5d635f7c  sp beb12380  lr 5d62ddec  pc 400e7438  cpsr 60000010  
  9.    
  10.  backtrace:  
  11.      #00  pc 00023438  /system/lib/libc.so   
  12.      #01  pc 00004de8  /data/app-lib/com.example.hellojni-2/libhello-jni.so  
  13.      #02  pc 000056c8  /data/app-lib/com.example.hellojni-2/libhello-jni.so  
  14.      #03  pc 00004fb4  /data/app-lib/com.example.hellojni-2/libhello-jni.so  
  15.      #04  pc 00004f58  /data/app-lib/com.example.hellojni-2/libhello-jni.so  
  16.      #05  pc 000505b9  /system/lib/libdvm.so  
  17.      #06  pc 00068005  /system/lib/libdvm.so  
  18.      #07  pc 000278a0  /system/lib/libdvm.so  
  19.      #08  pc 0002b7fc  /system/lib/libdvm.so  
  20.      #09  pc 00060fe1  /system/lib/libdvm.so  
  21.      #10  pc 0006100b  /system/lib/libdvm.so  
  22.      #11  pc 0006c6eb  /system/lib/libdvm.so  
  23.      #12  pc 00067a1f  /system/lib/libdvm.so  
  24.      #13  pc 000278a0  /system/lib/libdvm.so  
  25.      #14  pc 0002b7fc  /system/lib/libdvm.so  
  26.      #15  pc 00061307  /system/lib/libdvm.so  
  27.      #16  pc 0006912d  /system/lib/libdvm.so  
  28.      #17  pc 000278a0  /system/lib/libdvm.so  
  29.      #18  pc 0002b7fc  /system/lib/libdvm.so  
  30.      #19  pc 00060fe1  /system/lib/libdvm.so  
  31.      #20  pc 00049ff9  /system/lib/libdvm.so  
  32.      #21  pc 0004d419  /system/lib/libandroid_runtime.so  
  33.      #22  pc 0004e1bd  /system/lib/libandroid_runtime.so  
  34.      #23  pc 00001d37  /system/bin/app_process  
  35.      #24  pc 0001bd98  /system/lib/libc.so  
  36.      #25  pc 00001904  /system/bin/app_process  
  37.    
  38.  stack:  
  39.           beb12340  012153f8    
  40.           beb12344  00054290    
  41.           beb12348  00000035    
  42.           beb1234c  beb123c0  [stack]  
  43.        
  44. ……  

如果你看过logcat打印的NDK错误时的日志就会知道，我省略了后面很多的内容，很多人看到这么多密密麻麻的日志就已经头晕脑胀了，即使是很多资深的Android开发者，在面对NDK日志时也大都默默的选择了无视。


view plaincopy  
  1. adb shell logcat | ndk-stack -sym $PROJECT_PATH/obj/local/armeabi  

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

[plain] view plaincopy  
  1. ********** Crash dump: **********  
  2. Build fingerprint: 'vivo/bbk89_cmcc_jb2/bbk89_cmcc_jb2:4.2.1/JOP40D/1372668680:user/test-keys'  
  3. pid: 32607, tid: 32607, name: xample.hellojni  >>> com.example.hellojni <<<  
  4. signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000  
  5. Stack frame #00  pc 00023438  /system/lib/libc.so (strlen+72)  
  6. Stack frame #01  pc 00004de8  /data/app-lib/com.example.hellojni-2/libhello-jni.so (std::char_traits::length(char const*)+20): Routine std::char_traits::length(char const*) at /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/char_traits.h:229  
  7. Stack frame #02  pc 000056c8  /data/app-lib/com.example.hellojni-2/libhello-jni.so (std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&)+44): Routine basic_string at /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/_string.c:639  
  8. Stack frame #03  pc 00004fb4  /data/app-lib/com.example.hellojni-2/libhello-jni.so (willCrash()+68): Routine willCrash() at /home/testin/hello-jni/jni/hello-jni.cpp:69  
  9. Stack frame #04  pc 00004f58  /data/app-lib/com.example.hellojni-2/libhello-jni.so (JNI_OnLoad+20): Routine JNI_OnLoad at /home/testin/hello-jni/jni/hello-jni.cpp:61  
  10. Stack frame #05  pc 000505b9  /system/lib/libdvm.so (dvmLoadNativeCode(char const*, Object*, char**)+516)  
  11. Stack frame #06  pc 00068005  /system/lib/libdvm.so  
  12. Stack frame #07  pc 000278a0  /system/lib/libdvm.so  
  13. Stack frame #08  pc 0002b7fc  /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+180)  
  14. Stack frame #09  pc 00060fe1  /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+272)  
  15. ……（后面略）  

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

[plain] view plaincopy  
  1. #03 (willCrash()+68): Routine willCrash() at /home/testin/hello-jni/jni/hello-jni.cpp:69  
  2. #04 (JNI_OnLoad+20): Routine JNI_OnLoad at /home/testin/hello-jni/jni/hello-jni.cpp:61  

回想一下我们的代码，在JNI_OnLoad()函数中（第61行），我们调用了willCrash()函数；在willCrash()函数中（第69行），我们制造了一个错误。这些信息都被准确无误的提取了出来！是不是非常简单？

view plaincopy  
  1. adb shell logcat > 1.log  
  2. ndk-stack -sym $PROJECT_PATH/obj/local/armeabi –dump 1.log  

view plaincopy  
  1. /Developer/android_sdk/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/  

假设你的电脑是windows， CPU架构为mips，那么你要的工具可能包含在这个目录中：

[plain] view plaincopy  
  1. D:\ android-ndk-r9d\toolchains\mipsel-linux-android-4.8\prebuilt\windows-x86_64\bin\  

好了言归正传，如何使用这两个工具，下面具体介绍：

view plaincopy  
  1. arm-linux-androideabi-addr2line –e obj/local/armeabi/libhello-jni.so 00004de8 000056c8 00004fb4 00004f58  

结果如下 [plain] view plaincopy  
  1. /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/char_traits.h:229  
  2. /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/_string.c:639  
  3. /WordSpaces/hello-jni/jni/hello-jni.cpp:69  
  4. /WordSpaces hello-jni/jni/hello-jni.cpp:6  

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

view plaincopy  
  1. arm-linux-androideabi-objdump –S obj/local/armeabi/libhello-jni.so > hello.asm  

在生成的asm文件中查找刚刚我们定位的两个关键指针00004fb4和00004f58

从这两张图可以清楚的看到（要注意的是，在不同的NDK版本和不同的操作系统中，asm文件的格式不是完全相同，但都大同小异，请大家仔细比对），这两个指针分别属于willCrash()和JNI_OnLoad()函数，再结合刚才addr2line的结果，那么这两个地址分别对应的信息就是：

[plain] view plaincopy  
  1. 00004fb4: willCrash() /WordSpaces/hello-jni/jni/hello-jni.cpp:69  
  2. 00004f58: JNI_OnLoad()/WordSpaces/hello-jni/jni/hello-jni.cpp:61  

相当完美，和ndk-stack得到的信息完全一致！

使用Testin崩溃分析服务定位NDK错误

以上提到的方法，只适合在开发测试期间，如果你的应用或者游戏已经发布上线，而用户经常反馈说崩溃、闪退，指望用户帮你收集信息定位问题，几乎是不可能的。这个时候，我们就需要用其他的手段来捕获崩溃信息。

目前业界已经有一些公司推出了崩溃信息收集的服务，通过嵌入SDK，在程序发生崩溃时收集堆栈信息，发送到云服务平台，从而帮助开发者定位错误信息。在这方面，处于领先地位的是国内的Testin和国外的crittercism，其中crittercism需要付费，而且没有专门的中国开发者支持，我们更推荐Testin，其崩溃分析服务是完全免费的。

Testin从1.4版本开始支持NDK的崩溃分析，其最新版本已经升级到1.7。当程序发生NDK错误时，其内嵌的SDK会收集程序在用户手机上发生崩溃时的堆栈信息（主要就是上面我们通过logcat日志获取到的函数指针）、设备信息、线程信息等等，SDK将这些信息上报至Testin云服务平台，只要登陆到Testin平台，就可以看到所有用户上报的崩溃信息，包括NDK；并且这些崩溃做过归一化的处理，在不同系统和ROM的版本上打印的信息会略有不同，但是在Testin的网站上这些都做了很好的处理，避免了我们一些重复劳动。

上图的红框部分，就是从用户手机上报的，我们自己的so中报错的函数指针地址堆栈信息，就和我们开发时从logcat读到的日志一样，是一些晦涩难懂的指针地址，Testin为NDK崩溃提供了符号化的功能，只要将我们编译过程中产生的包含符号表的so文件上传（上文我们提到过的obj/local/目录下的适用于各个CPU架构的so），就可以自动将函数指针地址定位到函数名称和代码行数。符号化之后，看起来就和我们前面在本地测试的结果是一样的了，一目了然。

而且使用这个功能还有一个好处：这些包含符号表的so文件，在每次我们自己编译之后都会改变，很有可能我们刚刚发布一个新版本，这些目录下的so就已经变了，因为开发者会程序的修改程序；在这样的情况下，即使我们拿到了崩溃时的堆栈信息，那也无法再进行符号化了。所以我们在编译打包完成后记得备份我们的so文件。这时我们可以将这些文件上传到Testin进行符号化的工作，Testin会为我们保存和管理不同版本的so文件，确保信息不会丢失。来看一下符号化之后的显示：

 
androidndkcrash崩溃分析

相关

标签