Android JNI Crash定位步骤

1. 找到未strip的, 符号表完整的so库文件

在Android Studio 3.2.1:

strip之前的文件所在目录:
app/build/intermediaters/transforms/mergejniLibs/debug
或者根据Crash的APP是debug还是release版本选择
app/build/intermediates/cmake/debug/obj或app/build/intermediates/cmake/release/obj
由于CMake/CXX_FLAGS的配置等原因，以上目录下的文件可能还是被strip了。如何准确判断so有没有被strip请参照文章下面提到的readelf工具。
如果发现so还是被strip的，尝试在CMake添加如下配置：

/**
这几行代码表示debug版本的so文件保留so保留符号库，这样会导致so文件很大.
如果要让release版本保留符号库文件，就替换成CMAKE_C_FLAGS_RELEASE和CMAKE_CXX_FLAGS_RELEASE.
但务必在正式对外发布的时候去掉release 配置的-g选项，以免增加文件size
**/
set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -g")
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -g")
//R16之前版本的NDK默认是编译时加-g的，新版本不确定，所以需要不strip的 so文件，最好在CMake里配置一下-g
//并且不要有 -fvisibility=hidden 和 -s 选项！！

如果依赖的是Native module或者aar, 那么
strip之前的文件所在目录:
yourNativeLibModule/build/intermediates/transforms/mergeJniLibs/debug

strip之后的文件所在目录:
app/build/intermediaters/transforms/stripDebugSymbol/debug

2. 确定发生Crash的设备对应的CPU架构

在JNI Crash的日志里
如果有lib/arm, 则是armeabi-v7a架构;
如果有lib/arm64, 则是arm64-v8a架构

3. 根据CPU架构找相应的toolchain:

arm64-v8a对应的是aarch64-linux-android-4.9
armeabi-v7a对应的是arm-linux-androideabi-4.9

4.使用add2line 和ndk-stack等工具分析JNI Crash的log

addr2line

作用是根据内存地址找到对应的报错代码的文件名和行号
所在目录是toolchain的bin文件夹,
比如 aarch64-linux-android-4.9对应的bin文件夹是
/Android/Sdk/ndk-bundle/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin

arm-linux-androideabi-4.9,对应的bin文件夹是
/media/kyle/a393d005-ebe5-42a0-8c6a-c86fdfb185c1/Android/Sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin

用法:
arm-linux-androideabi-addr2line -f -e xxx.so 0x8eb09258
-f表示显示函数名, -e表示execution，后面是包含符号库的文件 以及报错的内存地址（即Crash log里pc后的字段）

ndk-stack

作用是一键生成更可读的Crash 日志
所在目录是/media/kyle/a393d005-ebe5-42a0-8c6a-c86fdfb185c1/Android/Sdk/ndk-bundle/ndk-stack
用法:
ndk-stack -sym App/build/intermediates/transforms/mergeJniLibs/release/0/lib/对应的abi目录 -dump jniCrash.log
或者
adb logcat | ndk-stack -sym App/build/intermediates/transforms/mergeJniLibs/release/0/lib/对应的abi目录

-sym表示symbols

--------------------------------------------分隔符----------------------------------------

其他工具补充

toolchain下的:

arm-linux-androideabi-readelf

1. 有时候用addr2line发现能显示函数名但行号是乱码？？，有可能是因为这个so被strip了。被strip的so的
   readelf结果里“section headers”的个数会比未strip后的少，所以可以根据readelf来判断so是否是真的被strip了
   命令格式：
   arm-linux-androideabi-readelf -S xx.so

2. 可以用于查看so文件中的所有函数。所以如果遇到JNI方法找不到的错误，就可以使用该工具查看so库中的所有函数，然后搜索对应的JNI方法，看到底有没有被编译到动态库中。
   命令格式：
   arm-linux-androideabi-readelf -a xx.so > fun.txt
   注意：仍需要使用未strip之前的so文件， 上面的命令会把结果写入fun.txt

arm-linux-androideabi-objdump

可以获取so文件的符号表信息，可以看到编译进来的所有方法以及调用堆栈的地址.
命令格式：
arm-linux-androideabi-objdump -dx xx.so > stacktrace.txt
或
/aarch64-linux-android-objdump -dx xx.so > stacktrace.txt

arm-linux-androideabi-nm

可以查看静态库中的符号，比如查看所有方法的声明。
如果在编译so动态库的过程中碰到undefined reference类型的错误， 或者
duplicated reference， 可以使用这条指令将对应静态库的所有方法都导出来， 然后看一下是否有某方法.
命令格式：
arm-linux-androideabi-nm xx.a > symbol.txt

常用信号量的含义

#define SIGABRT 6 // abort() 调用abort函数生成的信号，表示程序运行异常被中止
#define SIGSEGV 11 // segmentation violation 指针所对应的地址是无效或非法地址，比如访问越界/stack overflow/文件操作不被允许( fault addr 0x0 或者其他小地址 fault addr 0x0000008 一般是空指针错误，访问为null的结构体的成员变量时，报错地址会是小地址)
#define SIGILL 4 // Illegal instruction 执行了非法指令，比如第三方库的兼容性问题，权限问题
#define SIGSYS 31 // bad argument to system call 非法的系统调用
#define SIGBUS 7 // 非法地址，包括内存地址对齐出错，比如访问一个4字节的整数, 但其地址不是4的倍数
#define SIGFPE 8 // 进程执行了一个错误的算术操作，比如除0、溢出
#define SIGKILL 9 // 强制结束程序，本信号不能被捕获
#define SIGPIPE 13 // write on a pipe with no one to read it 管道破裂，通常在进程间通信产生

用AddressSanitizer检测内存问题

谷歌官方出品的AddressSanitizer，使用也比较简单。目前还不支持内存泄漏的检测，但支持检测以下内存问题：

• 堆栈和堆缓冲区上溢/下溢
• 释放之后的堆使用情况
• 超出范围的堆栈使用情况（比如数组越界）
• 重复释放/错误释放
  相关文章：
  Demo例子
  AddressSanitizerOnAndroid
  Android Native内存问题检测
  在AndroidStudio上使用AddressSanitizer

本文参考文章

Android NDK开发Crash错误定位
Can anyone explain the gcc cross-compiler naming convention?
NDK toolchain对应ABI
Android基础开发实践：如何分析Native Crash（文字介绍的“当前符号表so与实际出现Crash的so不匹配，但当前出问题的native函数没有进行过修改时仍可以解析”的方法很好用，记得加地址偏移时是16进制）
Android Stability - Native Crash问题概述
诊断原生代码崩溃问题

《音视频开发进阶指南》 by 展晓凯 魏晓红