Android-JNI开发系列《四》Native-Crash定位

人间观察

你有多久没有十点之前睡过觉了。

假期ing～～～

在Android中进行JNI的开发的当然也会发生crash，而发生crash后比较难定位。
因为jni是使用C/C++来进行开发的，熟悉C/C++语言的同学都知道，指针和内存申请的使用时需要自己申请和释放的，它不像java那样有jvm有垃圾回收管理机制gc，稍微管理不当就会导致问题。比如：内存地址访问错误、堆栈溢出、指针使用错误等等，最后都会导致程序崩溃。

幸好Android NDK提供了一些工具来帮助精确定位到出问题的代码。
我们模拟一下crash，模拟一个指针未初始化访问的case。

#include "common.h"
#include <malloc.h>extern "C"
JNIEXPORT void JNICALL
Java_com_bj_gxz_jniapp_crash_JNICrash_crash(JNIEnv *env, jobject thiz) {
//    int *p = static_cast<int *>(malloc(sizeof(int)));int *p;*p = 1;LOG_D("*P=%d", *p);free(p);
}

*p没有初始化
崩溃的日志如下:


2020-09-28 14:36:49.737 19047-19047/com.bj.gxz.jniapp A/libc: Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x6fcabb4d34 in tid 19047 (m.bj.gxz.jniapp), pid 19047 (m.bj.gxz.jniapp)
2020-09-28 14:36:49.856 19167-19167/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2020-09-28 14:36:49.856 19167-19167/? A/DEBUG: Build fingerprint: 'HONOR/STF-AL00/HWSTF:9/HUAWEISTF-AL00/9.1.0.219C00:user/release-keys'
2020-09-28 14:36:49.856 19167-19167/? A/DEBUG: Revision: '0'
2020-09-28 14:36:49.856 19167-19167/? A/DEBUG: ABI: 'arm64'
2020-09-28 14:36:49.857 19167-19167/? A/DEBUG: Happend: 'Mon Sep 28 14:36:49 2020'
2020-09-28 14:36:49.857 19167-19167/? A/DEBUG: SYSVMTYPE: ArtAPPVMTYPE: Art
2020-09-28 14:36:49.857 19167-19167/? A/DEBUG: pid: 19047, tid: 19047, name: m.bj.gxz.jniapp  >>> com.bj.gxz.jniapp <<<
2020-09-28 14:36:49.857 19167-19167/? A/DEBUG: signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x6fcabb4d34
2020-09-28 14:36:49.857 19167-19167/? A/DEBUG:     x0  0000006fcb0c5460  x1  0000007fdd935134  x2  0000006fac4b2b84  x3  0000000070cfc600
2020-09-28 14:36:49.857 19167-19167/? A/DEBUG:     x4  0000000000000000  x5  0000000000000000  x6  0000000000000000  x7  0000000000000000
2020-09-28 14:36:49.857 19167-19167/? A/DEBUG:     x8  0000000000000001  x9  0000000000000003  x10 0000006fac4b2b80  x11 0000006fcabb4d34
2020-09-28 14:36:49.857 19167-19167/? A/DEBUG:     x12 0000007051586630  x13 0f2fce861ea823e3  x14 000000705118b000  x15 ffffffffffffffff
2020-09-28 14:36:49.857 19167-19167/? A/DEBUG:     x16 0000006fac4990bc  x17 00000070507c5d48  x18 0000000000000001  x19 0000006fcb015c00
2020-09-28 14:36:49.857 19167-19167/? A/DEBUG:     x20 0000000000000000  x21 0000006fcb015c00  x22 0000007fdd935400  x23 0000006faeae68f1
2020-09-28 14:36:49.857 19167-19167/? A/DEBUG:     x24 0000000000000004  x25 00000070518f65e0  x26 0000006fcb015ca0  x27 0000000000000001
2020-09-28 14:36:49.857 19167-19167/? A/DEBUG:     x28 0000007fdd935130  x29 0000007fdd935100
2020-09-28 14:36:49.857 19167-19167/? A/DEBUG:     sp  0000007fdd9350e0  lr  0000006fcaeb6fe4  pc  0000006fac4990ec
2020-09-28 14:36:49.891 744-2617/? E/LOGSERVER_UTILS: [Erecovery]readEvent: eRecEventManager readEvent 0
2020-09-28 14:36:49.998 19167-19167/? A/DEBUG: backtrace:
2020-09-28 14:36:49.998 19167-19167/? A/DEBUG:     #00 pc 000000000000e0ec  /data/app/com.bj.gxz.jniapp-wTViTmvyh8_za4_TB4rqtQ==/lib/arm64/libnative-lib.so (Java_com_bj_gxz_jniapp_crash_JNICrash_crash+48)
2020-09-28 14:36:49.998 19167-19167/? A/DEBUG:     #01 pc 0000000000588fe0  /system/lib64/libart.so (art_quick_generic_jni_trampoline+144)
2020-09-28 14:36:49.998 19167-19167/? A/DEBUG:     #02 pc 000000000057ff88  /system/lib64/libart.so (art_quick_invoke_stub+584)
2020-09-28 14:36:49.998 19167-19167/? A/DEBUG:     #03 pc 00000000000d8608  /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+200)
2020-09-28 14:36:49.998 19167-19167/? A/DEBUG:     #04 pc 000000000028cec8  /system/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+344)
2020-09-28 14:36:49.998 19167-19167/? A/DEBUG:     #05 pc 0000000000286ed0  /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+968)
2020-09-28 14:36:49.998 19167-19167/? A/DEBUG:     #06 pc 000000000054747c  /system/lib64/libart.so (MterpInvokeVirtual+588)
2020-09-28 14:36:49.998 19167-19167/? A/DEBUG:     #07 pc 0000000000572514  /system/lib64/libart.so (ExecuteMterpImpl+14228)
2020-09-28 14:36:49.998 19167-19167/? A/DEBUG:     #08 pc 00000000001678da  /dev/ashmem/dalvik-classes.dex extracted in memory from /data/app/com.bj.gxz.jniapp-wTViTmvyh8_za4_TB4rqtQ==/base.apk (deleted) (com.bj.gxz.jniapp.MainActivity.onJniCrash+10)
2020-09-28 14:36:49.998 19167-19167/? A/DEBUG:     #09 pc 0000000000260bd4  /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.2850692617+488)
2//  ...省略其它日志不重要的日志

crash日志里最有用的backtrace信息。 backtrace描述了crash发生时函数的调用关系及其它地址信息等。
在backtrace中，从#00到#04 共五行信息代表是crash时函数调用关系，从下往上倒着看，#04行的方法调用了#03行的方法；#03行的方法调用了#02行的方法；向上类推，最后就是#01行的方法调用了#00行的方法。而最终出现的crash就是在#00行中。

如何定位解决呢？

使用ndk提供的命令addr2line

addr2line命令在ndk版本的toolchains目录下，我的是在

/Users/guxiuzhong/Library/Android/sdk/ndk/21.0.6113669/toolchains
B000000073160:toolchains guxiuzhong$ ls
aarch64-linux-android-4.9   renderscript
arm-linux-androideabi-4.9   x86-4.9
llvm                x86_64-4.9

从上面可以看得出来NDK针对不同的CPU架构实现了多套相同的工具，所以你要根据目标机器的CPU架构来选择。如果不知道目标机器的CPU架构，把手机连上电脑，用adb shell cat /proc/cpuinfo可以查看手机的CPU信息。我的目标机器是Processor : AArch64 Processor rev 1 (aarch64)

addr2line的使用方式是

addr2line -e 000000000000e0ec

-e 指定带符号表的so文件路径，也需要对应目标机器的CPU架构的so文件的绝对路径

000000000000e0ec 崩溃的汇编指令地址

addr2line一下

/Users/guxiuzhong/Library/Android/sdk/ndk/21.0.6113669/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-addr2line  -e /Users/guxiuzhong/Desktop/JNIAPP/app/build/intermediates/cmake/debug/obj/arm64-v8a/libnative-lib.so  000000000000e0ec

结果如下

/Users/guxiuzhong/Desktop/JNIAPP/app/src/main/cpp/crash.cpp:9

回看下我们.cpp的源码，第9行由于int* p指针没有初始化导致了fault addr。

使用ndk提供的命令ndk-stack

这个命令可以简化上面的步骤。

使用adb获取logcat的日志，并通过管道输出给ndk-stack进行分析。

ndk-stack -sym使用方式是

ndk-stack -sym XXXX

-sym 指定带符号表的so文件路径，也需要对应目标机器的CPU架构的so文件的根目录即可

ndk-stack一下

adb logcat | /Users/guxiuzhong/Library/Android/sdk/ndk/21.0.6113669/ndk-stack -sym /Users/guxiuzhong/Desktop/JNIAPP/app/build/intermediates/cmake/debug/obj/arm64-v8a

这时候模拟一下crash，检测到crash，ndk-stack自动解析了，结果和上面的一样第9行：

********** Crash dump: **********
Build fingerprint: 'HONOR/STF-AL00/HWSTF:9/HUAWEISTF-AL00/9.1.0.219C00:user/release-keys'
#00 0x000000000000e0ec /data/app/com.bj.gxz.jniapp-wTViTmvyh8_za4_TB4rqtQ==/lib/arm64/libnative-lib.so (Java_com_bj_gxz_jniapp_crash_JNICrash_crash+48)Java_com_bj_gxz_jniapp_crash_JNICrash_crash/Users/guxiuzhong/Desktop/JNIAPP/app/src/main/cpp/crash.cpp:9:8
#01 0x0000000000588fe0 /system/lib64/libart.so (art_quick_generic_jni_trampoline+144)
#02 0x000000000057ff88 /system/lib64/libart.so (art_quick_invoke_stub+584)

这个命令也支持文件的解析（使用-dump参数），这个好，因为有些crash不是必须的。

ndk-stack -dump 使用方式是

ndk-stack -sym XXXX -dump XXXX

-sym 指定带符号表的so文件路径，也需要对应目标机器的CPU架构的so文件的根目录即可
-dump crash的堆栈信息的文件

B000000073160:bin guxiuzhong$ /Users/guxiuzhong/Library/Android/sdk/ndk/21.0.6113669/ndk-stack -sym /Users/guxiuzhong/Desktop/JNIAPP/app/build/intermediates/cmake/debug/obj/arm64-v8a -dump  ~/Desktop/crash.log
********** Crash dump: **********
Build fingerprint: 'HONOR/STF-AL00/HWSTF:9/HUAWEISTF-AL00/9.1.0.219C00:user/release-keys'
#00 0x000000000000e0ec /data/app/com.bj.gxz.jniapp-wTViTmvyh8_za4_TB4rqtQ==/lib/arm64/libnative-lib.so (Java_com_bj_gxz_jniapp_crash_JNICrash_crash+48)Java_com_bj_gxz_jniapp_crash_JNICrash_crash/Users/guxiuzhong/Desktop/JNIAPP/app/src/main/cpp/crash.cpp:9:8
#01 0x0000000000588fe0 /system/lib64/libart.so (art_quick_generic_jni_trampoline+144)
#02 0x000000000057ff88 /system/lib64/libart.so (art_quick_invoke_stub+584)
#03 0x00000000000d8608 /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+200)
#04 0x000000000028cec8 /system/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+344)
#05 0x0000000000286ed0 /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+968)
#06 0x000000000054747c /system/lib64/libart.so (MterpInvokeVirtual+588)
#07 0x0000000000572514 /system/lib64/libart.so (ExecuteMterpImpl+14228)

总结：两种方法来定位crash。 addr2line -e xxxx 指定汇编指令地址。 adb logcat | ndk-stack -sym 指定对应目标机器的CPU架构的so文件的绝对路径； ndk-stack -dump 对应目标机器的CPU架构的so文件的根目录 -dump crash的堆栈信息的文件。