捕获与解析Android|捕获与解析Android NativeCrash

目录

  • 一、NE 简介
    • 1.1、so 组成
    • 1.2、查看 so 状态
    • 1.3、获取 strip 和未被 strip 的 so
  • 二、NE 捕获与解析
    • 2.1、logcat捕获
    • 2.2、通过DropBox日志解析--适用于系统应用
    • 2.3、通过BreakPad捕获解析--适用于所有应用
      • 2.3.1、BreakPad的实现功能
      • 2.3.2、BreakPad的捕获原理
      • 2.3.3、解析dump文件
      • 2.3.4、获取崩溃堆栈
  • 三、so符号表的提取
    • 3.1、提取 so 的符号表
      • 3.2、符号表分析
        • 3.2.1、直接分析
        • 3.2.2、工具解析
        • 3.2.3、偏移位置简析
    • 四、总结

      一、NE 简介 NE全称 NativeException,就是C或者C++运行过程中产生的错误,NE不同于普通的 Java 错误,普通的logcat无法直接还原成可阅读的堆栈,一般没有源码也无法调试。
      所以日常应用层的工程师,即使我们内部有云诊断的日志,一般也会忽略NE的错误,那么遇到这些问题,作为应用层、对C++不甚了解的工程师能否解决还原堆栈,能否快速定位或者解决NE的问题呢?
      下面将着重介绍:

      1.1、so 组成
      我们先了解一下 so 的组成,一个完整的 so 由C代码加一些 debug 信息组成,这些debug信息会记录 so 中所有方法的对照表,就是方法名和其偏移地址的对应表,也叫做符号表,这种 so 也叫做未 strip 的,通常体积会比较大。
      通常release的 so 都是需要经过一个strip操作的,这样strip之后的 so 中的debug信息会被剥离,整个 so 的体积也会缩小。
      如下图所示:
      捕获与解析Android|捕获与解析Android NativeCrash
      文章图片

      如下可以看到strip之前和之后的大小对比。
      捕获与解析Android|捕获与解析Android NativeCrash
      文章图片

      如果对 NE 或者 so 不了解的,可以简单将这个debug信息理解为Java代码混淆中的mapping文件,只有拥有这个mapping文件才能进行堆栈分析。
      如果堆栈信息丢了,基本上堆栈无法还原,问题也无法解决。
      所以,这些debug信息尤为重要,是我们分析NE问题的关键信息,那么我们在编译 so 时候务必保留一份未被strip的so 或者剥离后的符号表信息,以供后面问题分析,并且每次编译的so 都需要保存,一旦产生代码修改重新编译,那么修改前后的符号表信息会无法对应,也无法进行分析。

      1.2、查看 so 状态
      事实上,也可以通过命令行来查看 so 的状态,Mac下使用 file 命令即可,在命令返回值里面可以查看到so的一些基本信息。
      如下图所示,stripped代表是没有debug信息的so,with debug_info, not stripped代表携带debug信息的so。
      file libbreakpad-core-s.so
      libbreakpad-core-s.so: *******, BuildID[sha1]=54ad86d708f4dc0926ad220b098d2a9e71da235a, stripped
      file libbreakpad-core.so
      libbreakpad-core.so: ******, BuildID[sha1]=54ad86d708f4dc0926ad220b098d2a9e71da235a, with debug_info, not stripped
      如果你是 Windows系统的话,那么我劝你装一个 Linux子系统,然后在 Linux执行同样的命令,同样也可以得到该信息。
      接下来看下我们如何获取两种状态下的so。

      1.3、获取 strip 和未被 strip 的 so
      目前Android Studio无论是使用mk或者Cmake编译的方式都会同时输出strip和未strip的so,如下图是Cmake编译so产生的两个对应的so。
      strip之前的so路径:build/intermediates/transforms/mergeJniLibs
      strip之后的so路径:build/intermediates/transforms/stripDebugSymbol
      捕获与解析Android|捕获与解析Android NativeCrash
      文章图片

      另外也可以通过Android SDK提供的工具aarch64-linux-android-strip手动进行strip,aarch64-linux-android-strip这个工具位于/Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains目录下。
      这个工具有多种版本,主要针对不同的手机CPU架构,如果不知道手机的CPU架构,可以连接手机使用以下命令查看:
      adb shell cat /proc/cpuinfo
      Processor: AArch64 Processor rev 12 (aarch64)
      如上图可以看到我的手机CPU用的是aarch64,所以使用aarch64对应的工具aarch64-linux-android-strip,由于NDK提供了很多工具,后续都依照此原则使用即可:
      aarch64架构
      /Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-strip
      arm架构
      /Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-android-strip
      使用如下命令可以直接将debug的so进行strip
      aarch64-linux-android-strip --strip-all libbreakpad-core.so
      使用Cmake进行编译的时候,可以增加如下命令,可以直接编译出strip的so
      #set(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} -s")
      #set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -s")
      使用mk文件进行编译的时候,可以增加如下命令,也可以直接编译出strip的so
      -fvisibility=hidden

      二、NE 捕获与解析 NE解析顾名思议就是堆栈解析,当然所有的前提就是需要保存一份带符号表、也就是未被strip的so,如果你只有strip之后的so,那就无能为力了,堆栈基本无法还原了。
      一般有以下三种方式可以捕获和还原堆栈。

      2.1、logcat捕获
      顾名思义,就是通过logcat进行捕获,我们通过Android Studio打开logcat,制造一个NE,只能看到很多类似#00 pc 00000000000161a0的符号,并没有一个可以直接阅读的日志,我们想通过logcat直接输出一份可以直接阅读的log。
      可以使用Android/SDK/NDK下面提供的一个工具ndk-stack,它可以直接将NE输出的log解析为可阅读的日志。
      ndk-stack一般是位于ndk的工具下面,Mac下的地址为
      /Users/XXXX/Library/Android/sdk/ndk/21.3.6528147/ndk-stack
      然后在该目录下执行控制台命令,或者在 Android Studio的terminal中执行也可
      adb shell logcat | androidsdk绝对路径/ndk-stack -sym so所在目录
      如此控制台在应用发生NE的时候便会输出如下日志,由日志可以看出,崩溃对应的so以及对应的方法名,如果有c的源码,那么就很容易定位问题。
      promote:~ njvivo$ adb shell logcat | ndk-stack -sym libbreakpad-core.so
      ********** Crash dump: **********
      Build fingerprint: 'vivo/PD1809/PD1809:8.1.0/OPM1.171019.026/compil04252203:user/release-keys'
      #00 0x00000000000161a0 /data/app/com.android.necase-lEp0warh8FqicyY1YqGXXA==/lib/arm64/libbreakpad-core.so (Java_com_online_breakpad_BreakpadInit_nUpdateLaunchInfo+16)
      #01 0x00000000000090cc /data/app/com.android.necase-lEp0warh8FqicyY1YqGXXA==/oat/arm64/base.odex (offset 0x9000)
      Crash dump is completed
      其实ndk-stack这个工具原理就是内部集成利用了addr2line来实时解析堆栈并且显示在控制台中。
      看到这里有的小伙伴就觉得那这个不是很简单,但是实际的崩溃场景一是不容易复现,二是用户的场景有时候很难模拟,那么线上的NE崩溃又该如何监测和定位呢,有两种方式。

      2.2、通过DropBox日志解析--适用于系统应用
      这个很简单,DropBox会记录JE,NE,ANR的各种日志,只需要将DropBox下面的日志传上来即可进行分析解决,下面贴上一份日志示例。
      捕获与解析Android|捕获与解析Android NativeCrash
      文章图片

      解析方案1:
      借助上述的ndk-stack工具,可以直接将DropBox下面的日志解析成堆栈,从中可以看出,崩溃在breakpad.cpp第111行的Crash()方法中。
      ndk-stack -sym /Users/njvivo/Desktop/NE -dump data_app_native_crash@1605531663898.txt
      ********** Crash dump: **********
      Build fingerprint: 'vivo/PD1809/PD1809:8.1.0/OPM1.171019.026/compil04252203:user/release-keys'
      #00 0x00000000000161a0 /data/app/com.android.necase-lEp0warh8FqicyY1YqGXXA==/lib/arm64/libbreakpad-core.so (Java_com_online_breakpad_BreakpadInit_nUpdateLaunchInfo+16)
      Crash()
      /Users/njvivo/Documents/project/Breakpad/breakpad-build/src/main/cpp/breakpad.cpp:111:8
      Java_com_online_breakpad_BreakpadInit_nUpdateLaunchInfo
      /Users/njvivo/Documents/project/Breakpad/breakpad-build/src/main/cpp/breakpad.cpp:122:0
      #01 0x00000000000090cc /data/app/com.android.necase-lEp0warh8FqicyY1YqGXXA==/oat/arm64/base.odex (offset 0x9000)
      Crash dump is completed
      解析方案2:
      还是利用Android/SDK/NDK提供的工具linux-android-addr2line,这个工具位于/Users/njvivo/Library/Android/sdk/ndk目录下,有两个版本。
      aarch64架构
      /Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-addr2line
      arm架构
      /Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-addr2line
      命令使用方法如下,结合未被strip的so以及日志里面出现的堆栈符号00000000000161a0,同样可以解析出崩溃地址和方法
      aarch64-linux-android-addr2line -f -C -e libbreakpad-core.so 00000000000161a0
      Crash()
      /Users/njvivo/Documents/project/Breakpad/breakpad-build/src/main/cpp/breakpad.cpp:111
      基于以上,看似也很简单,但是有一个致命的问题就是DropBox只有系统应用能访问,非系统应用根本拿不到日志,那么,非系统应用该怎么办呢?

      2.3、通过BreakPad捕获解析--适用于所有应用
      非系统应用可以通过google提供的开源工具BreakPad进行监测分析,CrashSDK也是采用的此种方式,可以实时监听到NE的发生,并且记录相关的文件, 从而可以将崩溃和相应的应用崩溃时的启动、场景等结合起来上报。
      下面简单介绍一下BreakPad的使用方式。

      2.3.1、BreakPad的实现功能 BreakPad主要提供两个个功能,NE的监听和回调,生成minidump文件,也就是dmp结尾的文件,另外提供两个工具,符号表工具和堆栈还原工具。
      捕获与解析Android|捕获与解析Android NativeCrash
      文章图片

      • 符号表工具:用于从so中提取出debug信息,获取到堆栈对应的符号表。
      • 堆栈还原工具:用于将BreakPad生成的dump文件还原成符号,也就是堆栈偏移值。
      这两个工具会在编译BreakPad源码的时候产生。
      编译完之后会产生minidump_stackwalk工具,有些同学不想编译的话,Android Studio本身也提供了这个工具。
      这个minidump_stackwalk程序在Android Studio的目录下面也存在,可以拿出来直接使用,如果不想编译的话,直接到该目录下面取即可,Mac路径为:
      /Applications/Android Studio.app/Contents/bin/lldb/bin/minidump_stackwalk

      2.3.2、BreakPad的捕获原理 由上述可以得知,BreakPad在应用发生NE崩溃时,可以将NE对应的minidump文件写入到本地,同时会回调给应用层,应用层可以针对本次崩溃做一些处理,达到捕获统计的作用,后续将minidump文件上传之后结合minidump_stackwalk以及addr2line工具可以还原出实际堆栈,示意图如下:
      捕获与解析Android|捕获与解析Android NativeCrash
      文章图片

      在应用发生NE时,BreakPad会在手机本地生成一个dump文件,如图所示:
      捕获与解析Android|捕获与解析Android NativeCrash
      文章图片

      得到了以上文件,我们只能知道应用发生了NE,但是这些文件其实是不可读的,需要解析这些文件。
      下面着重讲一下如何分析上面产生的NE:

      2.3.3、解析dump文件 1、获取NE崩溃的dump文件,将刚才得到的minidump_stackwalk和dump文件放在同一个目录,也可以不放,填写路径的时候填写绝对路径即可。
      然后在该目录下的终端窗口执行以下命令,该命令表示用minidump_stackwalk解析dump文件,解析后的信息输出到当前目录下的crashLog.txt文件。
      ./minidump_stackwalk xxxxxxxx.dmp >crashLog.txt
      2、执行完之后,minidump_stackwalk会将NE的相关信息写到crashLog.txt里面,详细信息如图所示:
      捕获与解析Android|捕获与解析Android NativeCrash
      文章图片

      3、根据解析出的NE信息,关注图中红框,可以得知,这个崩溃发生的libbreakpad-core.so里面,0x161a0代表崩溃发生在相对根位置偏移161a0的位置

      2.3.4、获取崩溃堆栈 1、利用之前提到的addr2line工具,可以根据发生Crash的so文件以及偏移地址(0x161a0)可以得出产生crash的方法、行数和调用堆栈关系。
      2、在其根目录对的终端窗口运行以下命令。
      arm-linux-androideabi-addr2line -C -f -e ${SOPATH} ${Address}
      -C -f//打印错误行数所在的函数名称
      -e//打印错误地址的对应路径及行数
      ${SOPATH}//so库路径
      ${Address}//需要转换的堆栈错误信息地址,可以添加多个,但是中间要用空格隔开,例如:0x161a0
      3、如下图是真实运行的示例
      aarch64-linux-android-addr2line -f -C -e libbreakpad-core.so 0x161a0
      Crash()
      /Users/njvivo/Documents/project/Breakpad/breakpad-build/src/main/cpp/breakpad.cpp:111
      由上图可以知道,该崩溃发生在breakpad.cpp文件的第111行,函数名是Crash(),与真实的文件一致,崩溃代码如下:
      void Crash() {volatile int *a = (int *) (NULL); *a = 1; //此处在代码里是111行}extern "C"JNIEXPORT void JNICALLJava_com_online_breakpad_BreakpadInit_nUpdateLaunchInfo(JNIEnv *env, jobject instance,jstring mLaunchInfoStr_) {DO_TRY{Crash(); const char *mLaunchInfoStr = env->GetStringUTFChars(mLaunchInfoStr_, 0); launch_info = (char *) mLaunchInfoStr; //env->ReleaseStringUTFChars(mLaunchInfoStr_, mLaunchInfoStr); }DO_CATCH("updateLaunchInfo"); }

      基于以上,便可以通过应用收集的dump文件解析的NE的详细堆栈信息。

      三、so符号表的提取
      3.1、提取 so 的符号表
      通过以上内容,我们知道,so中包含了一些debug信息,又叫做符号表,那么我们如何将这些debug信息单独剥离出来呢,ndk也给我们提供了相关的工具。
      aarch64架构
      /Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-objdump
      arm架构
      /Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-android-objdump
      如下是命令运行的方式,通过此命令,可以将so中的debug信息提取到文件中。
      promote:~ njvivo$ aarch64-linux-android-objdump -S libbreakpad-core.so > breakpad.asm

      3.2、符号表分析

      3.2.1、直接分析 如下图所示就是输出的符号表文件,结合上面的log以及下面的符号表文件,我们同样可以分析出堆栈。
      如log中所示,已经表明了崩溃地址是161a0,而161a0对应的代码是*a=1,由上面的分析我们已经知道该崩溃是在breakpad.cpp的111行,也就是*a=1的位置,完全符合预期。
      backtrace:
      #00 pc 00000000000161a0 /data/app/com.android.necase-lEp0warh8FqicyY1YqGXXA==/lib/arm64/libbreakpad-core.so (Java_com_online_breakpad_BreakpadInit_nUpdateLaunchInfo+16)
      #01 pc 00000000000090cc /data/app/com.android.necase-lEp0warh8FqicyY1YqGXXA==/oat/arm64/base.odex (offset 0x9000)
      捕获与解析Android|捕获与解析Android NativeCrash
      文章图片


      3.2.2、工具解析 google提供了一个Python的工具,将符号表和log结合起来可以直接分析出堆栈
      执行命令,就可以解析出相关堆栈,该工具可以用于服务端批量进行解析,此处不再详细说明。
      python parse_stack.py

      3.2.3、偏移位置简析 上面文章提到了一个偏移位置的概念,笔者对此了解也不多,不过大致有一个概念,C代码有一个根位置的代码的,每行代码相对根代码都有一个偏移位置。
      如上图示例log中有一行语句(Java_com_online_breakpad_BreakpadInit_nUpdateLaunchInfo+16),+16就是代表相对nUpdateLaunchInfo方法的位置往后偏移16。
      由上图可以看到,nUpdateLaunchInfo方法的位置是16190,偏移16,也就是16190+10(10进制的16转化16进制后为10)=161a0,同日志输出的一样。

      四、总结 以上就是本篇文章的所有内容,主要简述了so的一些基础知识,以及Android中NE的崩溃,捕获解析方案,希望通过该文档对涉及到NE相关的小伙伴带来帮助,同时后续CrashSDK也会支持相关NE的解析功能。
      【捕获与解析Android|捕获与解析Android NativeCrash】以上就是捕获与解析Android NativeCrash的详细内容,更多关于Android NativeCrash的资料请关注脚本之家其它相关文章!

        推荐阅读