Android Crash监控

Android 监控 Crash

从Android系统全局来看，Crash通常分为App/Framework Crash，Native Crash，以及Kernel Crash。

• 对于App层或者Framework层的Crash（也就是Java层面的Crash），主要是出现了未捕获异常，导致程序异常退出
• Native Crash，介于系统framework层与Linux层之间的一层，一般是因为Native层代码触发了系统的signal信号，导致程序异常退出
• Kernel Crash，很多情况是发生kernel panic，对于崩溃往往是驱动或者硬件出现故障

这里主要是分析Java层的Crash和Native层的Crash。这两种Crash的监控和获取堆栈信息的不同。

Java Crash

Java的Crash监控相对比较容易，Java中的Thread定义了一个接口：uncaughtExceptionHandler；用于出于未捕获的异常导致线程的终止（这里catch了是捕获不到的），当我们的应用crash的时候，就会回调走uncaughtExceptionHandler.uncaughtException，在该方法中可以获取到异常的信息，通过Thread.setDefaultUncaughtExceptionHandler该方法来设置线程的默认异常处理器，可以将异常信息保存到本地或者上传到服务器，方便我们快速的定位问题。

class MyCrashHandle : Thread.UncaughtExceptionHandler{private lateinit var defaultUncaughtExceptionHandler:Thread.UncaughtExceptionHandlerprivate lateinit var mContext:Contextfun  init(context: Context){mContext = contextdefaultUncaughtExceptionHandler = Thread.getDefaultUncaughtExceptionHandler()!!Thread.setDefaultUncaughtExceptionHandler(this)}//没有try catch导致程序崩溃的异常，在这里接收//1.崩溃的线程2,堆栈信息override fun uncaughtException(t: Thread, e: Throwable) {val dir = File(mContext.externalCacheDir,"crash_info")//创建私有目录if(!dir.exists()){dir.mkdirs()}val time = System.currentTimeMillis()val file = File(dir,"${time}.txt")val pw = PrintWriter(FileWriter(file))pw.println("time.xxx") //崩溃时间pw.println("thread: " + t.name) //崩溃的线程e.printStackTrace(pw) //错误堆栈pw.flush()pw.close()//采集到信息后，让系统默认的killHandler处理，弹出对话框，退出程序if(defaultUncaughtExceptionHandler!=null){defaultUncaughtExceptionHandler.uncaughtException(t,e)}}
}

生成的本地文件

Java捕获未处理异常机制

通过打印系统默认的java未捕获异常处理，可以看到代码在Runtimeinit的killApplicationHandler

RuntimeInit.java

@UnsupportedAppUsage
protected static final void commonInit() {if (DEBUG) Slog.d(TAG, "Entered RuntimeInit!");/** set handlers; these apply to all threads in the VM. Apps can replace* the default handler, but not the pre handler.*/LoggingHandler loggingHandler = new LoggingHandler();RuntimeHooks.setUncaughtExceptionPreHandler(loggingHandler);Thread.setDefaultUncaughtExceptionHandler(new KillApplicationHandler(loggingHandler));/** Install a time zone supplier that uses the Android persistent time zone system property.*/RuntimeHooks.setTimeZoneIdSupplier(() -> SystemProperties.get("persist.sys.timezone"));/** Sets handler for java.util.logging to use Android log facilities.* The odd "new instance-and-then-throw-away" is a mirror of how* the "java.util.logging.config.class" system property works. We* can't use the system property here since the logger has almost* certainly already been initialized.*/LogManager.getLogManager().reset();new AndroidConfig();/** Sets the default HTTP User-Agent used by HttpURLConnection.*/String userAgent = getDefaultUserAgent();System.setProperty("http.agent", userAgent);/** Wire socket tagging to traffic stats.*/TrafficStats.attachSocketTagger();initialized = true;
}

private static class KillApplicationHandler implements Thread.UncaughtExceptionHandler {private final LoggingHandler mLoggingHandler;/*** Create a new KillApplicationHandler that follows the given LoggingHandler.* If {@link #uncaughtException(Thread, Throwable) uncaughtException} is called* on the created instance without {@code loggingHandler} having been triggered,* {@link LoggingHandler#uncaughtException(Thread, Throwable)* loggingHandler.uncaughtException} will be called first.** @param loggingHandler the {@link LoggingHandler} expected to have run before*     this instance's {@link #uncaughtException(Thread, Throwable) uncaughtException}*     is being called.*/public KillApplicationHandler(LoggingHandler loggingHandler) {this.mLoggingHandler = Objects.requireNonNull(loggingHandler);}@Overridepublic void uncaughtException(Thread t, Throwable e) {try {ensureLogging(t, e);// Don't re-enter -- avoid infinite loops if crash-reporting crashes.if (mCrashing) return;mCrashing = true;// Try to end profiling. If a profiler is running at this point, and we kill the// process (below), the in-memory buffer will be lost. So try to stop, which will// flush the buffer. (This makes method trace profiling useful to debug crashes.)if (ActivityThread.currentActivityThread() != null) {ActivityThread.currentActivityThread().stopProfiling();}// Bring up crash dialog, wait for it to be dismissedActivityManager.getService().handleApplicationCrash(mApplicationObject, new ApplicationErrorReport.ParcelableCrashInfo(e));} catch (Throwable t2) {if (t2 instanceof DeadObjectException) {// System process is dead; ignore} else {try {Clog_e(TAG, "Error reporting crash", t2);} catch (Throwable t3) {// Even Clog_e() fails!  Oh well.}}} finally {// Try everything to make sure this process goes away.Process.killProcess(Process.myPid());System.exit(10);}}

private void ensureLogging(Thread t, Throwable e) {if (!mLoggingHandler.mTriggered) {try {mLoggingHandler.uncaughtException(t, e);} catch (Throwable loggingThrowable) {// Ignored.}}
}

生成到对应错误堆栈信息后，再结合mapping混淆文件，就可以比较方便快速的定位问题。

Natvie Crash

Linux信号机制

信号机制是Linux进程间通信的一种重要方式，Linux信号一方面用于正常的进程间通信和同步，另一方面它还负责监控系统异常及中断。当应用程序运行异常时，Linux内核将产生错误信号并通知给当前进程。当前进程在接收到该错误信号后，有三种不同的处理方式

• 忽略该信号
• 捕获该信号并执行对应的信号处理程序
• 执行该信号的缺省操作(默认操作，如终止进程)

当Linux应用程序在执行过程时发生严重错误，一般会导致程序崩溃。其中，Linux专门提供了一类crash信号，在程序接受到此信号的时候，缺省操作就是将崩溃的现场信息记录到核心文件(coredump是Linux内核提供的一个原生机制，当程序收到某些致命信号，系统会将当前进程的内存状态完整保留到磁盘上，形成一个二进制文件)，然后终止进程。

常见崩溃信号列表：

信号	描述
SIGSEGV（Segment Violation）	段错误，内存引用无效（如空指针，野指针）
SIGBUS（Bus Error）	总线错误，访问内存对象的未定义部分
SIGFPE（Floating Point Exception）	算术运算错误，如除以0
SIGILL（IIIegal Instruction）	非法指令，执行垃圾或特权指令
SIGSYS（Bad System Call）	错误系统调用
SIGXCPU（CPU Time Limit Exceeded）	CPU时间超限
SIGXFSZ（File Size Limit Exceeded）	文件大小超限

一般的出现崩溃信号，Android系统默认操作是直接退出我们的程序。但是系统允许我们给某一个进程的某一个特定的信号注册一个相应的处理函数（signal），也就对信号的默认处理动作进行修改。因此在对Native层NDK Crash的监控可以采用这种信号机制，捕获崩溃信号执行我们自己的信号处理函数，有点类式上面的java异常捕获。

breakPad

Google breakpad是一个跨平台的崩溃转储和分析框架的工具集合，breakpad在Linux中的实现就是借助Linux信号捕获机制实现的。因为其实现为c/c++，因此在Android是使用需要借助NDK工具。

开源地址：https://github.com/google/breakpad。

Breakpad主要由三部分组成：

• Client，编译进入项目中，随着项目一起编译发布，发布出去的so是strip掉debug信息的，当在用户手机上崩溃的时候，生成minidump文件
• Symbol Dumper（dump_syms工具），当在编译so的时候，除了编译strip后的so文件，还得保留strip前的so。dump_syms就是用来从strip前的so提取符号信息.sym文件（BreakPad格式的符号文件）
• minidump Processor（minidump_stackwalk工具），这个工具通过minidump_stackwalk指令，从.sym符号文件和包含崩溃信息的minidump文件中提取出完整的崩溃时的堆栈信息，最后生成我们可读的C/C++堆栈

minidump文件：

minidump是一种轻量级的崩溃转储格式，由微软提出并广泛应用于Windows平台上的应用程序崩溃处理机制中，相比于完整的core dump，minidump只记录了必要的调试信息，以减少文件大小。不同平台生成的dump格式不同分析工具不同，minidump可以实现各个平台dump文件统一。

引入项目

将Breakpad源码下载解压，查看README.ANDROID文件

打开README.ANDROID

1.导入android/google_breakpad/Android.mk中

2.在自己的Android.mk中加入这些breadpad依赖

LOCAL_PATH := $(call my-dir)/../..# Defube the client library module, as a simple static library that
# exports the right include path / linker flags to its users.include $(CLEAR_VARS)#最后编译出 libbreakpad_client.a
LOCAL_MODULE := breakpad_client
# 指定c++源文件后缀名
LOCAL_CPP_EXTENSION := .cc# 强制关键系统以32位arm模式生成模块的对象文件
LOCAL_ARM_MODE := arm# 需要编译的源文件
LOCAL_SRC_FILES := \src/client/linux/crash_generation/crash_generation_client.cc \src/client/linux/dump_writer_common/thread_info.cc \src/client/linux/dump_writer_common/ucontext_reader.cc \src/client/linux/handler/exception_handler.cc \src/client/linux/handler/minidump_descriptor.cc \src/client/linux/log/log.cc \src/client/linux/microdump_writer/microdump_writer.cc \src/client/linux/minidump_writer/linux_dumper.cc \src/client/linux/minidump_writer/linux_ptrace_dumper.cc \src/client/linux/minidump_writer/minidump_writer.cc \src/client/linux/minidump_writer/pe_file.cc \src/client/minidump_file_writer.cc \src/common/convert_UTF.cc \src/common/md5.cc \src/common/string_conversion.cc \src/common/linux/breakpad_getcontext.S \src/common/linux/elfutils.cc \src/common/linux/file_id.cc \src/common/linux/guid_creator.cc \src/common/linux/linux_libc_support.cc \src/common/linux/memory_mapped_file.cc \src/common/linux/safe_readlink.cc# 导入头文件
LOCAL_C_INCLUDES        := $(LOCAL_PATH)/src/common/android/include \$(LOCAL_PATH)/src \$(LSS_PATH)
#使用android ndk中的日志库log
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_C_INCLUDES)
LOCAL_EXPORT_LDLIBS     := -llog# 编译static静态库，类似java的jar包
include $(BUILD_STATIC_LIBRARY)

但是目前NDK默认的构建工具是CMake，通过CMake的方式来添加breakpad，而不是早期Android.mk的方式

通过对照Android.mk文件，我们在自己项目的cpp(也就是工程目录中c/c++源码)目录下创建breakpad目录，并将下载的breakpad源码根目录下的src目录(因此引用breakpad的源文件都在src目录中)复制到我们的项目中：

然后在breakpad目录下创建CMakeList.txt文件

cmake_minimum_required(VERSION 3.22.1)#头文件目录(这样在.cc文件中导入include文件，就可以省略写这个路径)
include_directories(src src/common/android/include)#开启arm汇编支持，因为导入源文件中有.s文件(汇编源码)
enable_language(ASM)# 生成libbreakpad.a并指定源码，对应android.mk中的LOCAL_SRC_FILES加上LOCAL_MODULE
add_library( breakpad STATICsrc/client/linux/crash_generation/crash_generation_client.ccsrc/client/linux/dump_writer_common/thread_info.ccsrc/client/linux/dump_writer_common/ucontext_reader.ccsrc/client/linux/handler/exception_handler.ccsrc/client/linux/handler/minidump_descriptor.ccsrc/client/linux/log/log.ccsrc/client/linux/microdump_writer/microdump_writer.ccsrc/client/linux/minidump_writer/linux_dumper.ccsrc/client/linux/minidump_writer/linux_ptrace_dumper.ccsrc/client/linux/minidump_writer/minidump_writer.ccsrc/client/linux/minidump_writer/pe_file.ccsrc/client/minidump_file_writer.ccsrc/common/convert_UTF.ccsrc/common/md5.ccsrc/common/string_conversion.ccsrc/common/linux/breakpad_getcontext.Ssrc/common/linux/elfutils.ccsrc/common/linux/file_id.ccsrc/common/linux/guid_creator.ccsrc/common/linux/linux_libc_support.ccsrc/common/linux/memory_mapped_file.ccsrc/common/linux/safe_readlink.cc
)# 链接ndk中的log，对应android.mk中 LOCAL_EXPORT_LDLIBS
target_link_libraries(breakpad log)

在Cpp目录下(breakpad同级)还有一个CMakeList.text文件

cmake_minimum_required(VERSION 3.22.1)project("ndkcrash")#因为ndkcrash.cpp用到#include "breakpad/src/client/linux/handler/minidump_descriptor.h"
##include "breakpad/src/client/linux/handler/exception_handler.h"，所以也要导入
include_directories(breakpad/src breakpad/src/common/android/include)#引入breakpad的cmakeList，执行并且生成libbreakpad.a(api的实现，类似java的jar包)
add_subdirectory(breakpad)# 编译之后会生成一个lib${CMAKE_PROJECT_NAME}.so的文件，SHARED生成so，STATIC生成a，生成对应.so文件的源文件为ndkcrash.cpp
add_library(${CMAKE_PROJECT_NAME} SHAREDndkcrash.cpp)# 链接android log,breadpad库到项目中，这样ndkcrash.cpp文件就能用库里的代码
target_link_libraries(${CMAKE_PROJECT_NAME}androidlogbreakpad
)

ndk_crash.cpp源文件中的实现为：

#include <jni.h>
#include <string>
#include <android/log.h>
#include "client/linux/handler/minidump_descriptor.h"
#include "client/linux/handler/exception_handler.h"extern "C" JNIEXPORT jstring JNICALL
Java_com_example_ndkcrash_NativeLib_stringFromJNI(JNIEnv* env,jobject /* this */) {std::string hello = "Hello from C++";return env->NewStringUTF(hello.c_str());
}extern "C"
JNIEXPORT void JNICALL
Java_com_example_ndkcrash_NativeCrashHandle_testNativeCrash(JNIEnv *env, jobject thiz) {__android_log_print(ANDROID_LOG_INFO,"native","xxxxxxxxxx");int * p = NULL;*p = 10;
}bool DumpCallback(const google_breakpad::MinidumpDescriptor& descriptor,void* context,bool succeeded) {//printf("Dump path: %s\n", descriptor.path());__android_log_print(ANDROID_LOG_INFO,"native","path:= %s",descriptor.path());//如果回调返回true，Breakpad将把异常视为已完全处理，禁止任何其他处理程序收到异常通知。//如果回调返回false，Breakpad会将异常视为未处理，并允许其他处理程序处理它。return false;
}extern "C"
JNIEXPORT void JNICALL
Java_com_example_ndkcrash_NativeCrashReport_initNativeCrash(JNIEnv *env, jobject thiz,jstring path_) {//拿到java传递过来的pathconst char * path = env->GetStringUTFChars(path_,0);//开启breakpad crash监控google_breakpad::MinidumpDescriptor descriptor(path);//官方demo没用到static，我们这里要加static让其生命周期在程序运行期间，不加的话当initNativeCrash方法执行完后，会执行对应的析构函数，关闭监控static google_breakpad::ExceptionHandler eh(descriptor, nullptr, DumpCallback,nullptr, true, -1);env->ReleaseStringUTFChars(path_,path);
}

JNI方法的方法名对应了Java类，创建源文件com_example_ndkcrash_NativeCrashReport

package com.example.ndkcrashimport android.content.Context
import java.io.Fileclass NativeCrashReport {companion object {// Used to load the 'ndkcrash' library on application startup.init {//会生成ndkcrash.so文件，引入这个供java调用System.loadLibrary("ndkcrash")}}fun init(context:Context){// 给定ndk crash监控的存储路径val applicationContext = context.applicationContextval file = File(applicationContext.externalCacheDir,"native_crash")if(!file.exists()){file.mkdirs()}initNativeCrash(file.absolutePath)}external fun initNativeCrash(path:String)}

这个时候如果出现NDK Crash，会在指定的目录：/sdcard/Android/Data/[packageName]/cache/native_crash下生成NDK Crash信息的文件

Crash解析

采集到的Crash信息记录在minidump文件中。minidump是由微软开发的用于崩溃上传的文件格式。我们可以通过将此文件上传到服务器完成上报，但是这个文件是没有可读性的，要将文件解析为可读的崩溃堆栈需要按照breakpad文档编译minidump_stackwalk工具。在AndroidStudio的安装目录下的plugins\android-ndk\resources\lldb\bin里就存在一个对应平台的minidump_stackwalk。

解析miniudump文件

1.dump_syms提取not striped so库的符号信息

./dump_syms libnativelib.so > libnativelib.so.sym

2.根据1中生成的libbreakpad-core.so.sym生成特定的目录结构

├── symbol
│   └── libnativelib.so
│       └── 7101a9976989ac0174715fca686ca5ed0
│           └── libnativelib.so.sym

命令如下：

head -n1 libnativelib.so.sym 
MODULE Linux arm64 7101A9976989AC0174715FCA686CA5ED0 libnativelib.so
​
mkdir -p ./symbol/libnativelib.so/7101A9976989AC0174715FCA686CA5ED0
​
mv libnativelib.so.sym ./symbol/libnativelib.so/7101A9976989AC0174715FCA686CA5ED0/

3.再利用minidump_stackwalk命令，将dmp文件和sym文件合成可读的crashinfo.txt

./minidump_stackwalk _ccrash.dmp ./symbol > crashinfo.txt

大概内容

Operating system: Android0.0.0 Linux 5.4.86-qgki-ga5eec0eb1e4c #1 SMP PREEMPT Wed Apr 13 23:55:10 CST 2022 aarch64
CPU: arm648 CPUs
​
GPU: UNKNOWN
​
Crash reason:  SIGSEGV /0x00000000
Crash address: 0x0
Process uptime: not available
​
Thread 0 (crashed)0  libnativelib.so!Java_com_example_nativelib_NativeLib_mockNativeCrash [nativelib.cpp : 20]
......1  libnativelib.so!Java_com_example_nativelib_NativeLib_mockNativeCrash [nativelib.cpp : 18]
......2  libart.so + 0xd7644
......
......

使用dump_syms的时候有个问题，Android是属于Linux系统的，所以编译得到的dump_syms必须在Linux系统上运行。但是大部分时候是没有在Linux环境上运行dump_syms的。有两种办法，一种是提供各个平台通用的符号表提取工具；第二种是使用minidump_stackwalk解析dmp时，先不指定symbol文件，当产生崩溃时，用户想要查看崩溃信息，此时再通过addr2line 进行解析。

使用这里的工具执行：

minidump_stackwalk xxxx.dump > crash.txt

生成crash.txt打开内容

Operating system: Android0.0.0 Linux 6.6.30-android15-7-gbb616d66d8a9-ab11968886 #1 SMP PREEMPT Thu Jun 13 23:09:10 UTC 2024 x86_64
CPU: amd64 //abi类型family 6 model 6 stepping 34 CPUsGPU: UNKNOWNCrash reason:  SIGSEGV //段错误，内容引用无效
Crash address: 0x0
Process uptime: not availableThread 0 (crashed)     //出现crash的线程0  base.apk + 0x4ad46 //16进制数 寄存器的信息rax = 0x0000000000000000   rdx = 0x0000000000000002rcx = 0x26ddd657b175b526   rbx = 0x00007f6778919380rsi = 0x00007ffc5b6e1bd0   rdi = 0x00007ffc5b6e2fbcrbp = 0x00007ffc5b6e3440   rsp = 0x00007ffc5b6e3420r8 = 0x00007ffc5b787080    r9 = 0x00007ffc5b7870a0r10 = 0x0000000000494e22   r11 = 0x0000000000000202r12 = 0x00007ffc5b6e3620   r13 = 0x00007f6778919428r14 = 0x00007ffc5b6e3950   r15 = 0x00007ffc5b6e3950rip = 0x00007f6660394d46Found by: given as instruction pointer in context1  libart.so + 0x2b5ecrbp = 0x00007ffc5b6e3460   rsp = 0x00007ffc5b6e3450rip = 0x00007f666482b5ecFound by: previous frame's frame pointer2  libart.so + 0x2b59crsp = 0x00007ffc5b6e34a0   rip = 0x00007f666482b59cFound by: stack scanning3  boot.art] + 0x1f8e00rsp = 0x00007ffc5b6e34b8   rip = 0x00000000701d0e00Found by: stack scanning4  libart.so + 0x12155rsp = 0x00007ffc5b6e3530   rip = 0x00007f6664812155Found by: stack scanning5  libart.so + 0x274bf6rsp = 0x00007ffc5b6e3590   rip = 0x00007f6664a74bf6Found by: stack scanning6  libart.so + 0x3f92f4rsp = 0x00007ffc5b6e3620   rip = 0x00007f6664bf92f4Found by: stack scanning7  libart.so + 0x3f8bbersp = 0x00007ffc5b6e3670   rip = 0x00007f6664bf8bbeFound by: stack scanning8  libart.so + 0x58f940rsp = 0x00007ffc5b6e3680   rip = 0x00007f6664d8f940Found by: stack scanning9  libart.so + 0x33102rsp = 0x00007ffc5b6e37a0   rip = 0x00007f6664833102Found by: stack scanning
10  libart.so + 0x2a6cabrsp = 0x00007ffc5b6e37e0   rip = 0x00007f6664aa6cabFound by: stack scanning
11  libart.so + 0x2a64edrsp = 0x00007ffc5b6e3820   rip = 0x00007f6664aa64edFound by: stack scanning
12  libart.so + 0x2a6036rsp = 0x00007ffc5b6e3860   rip = 0x00007f6664aa6036Found by: stack scanning
13  libart.so + 0x560285rsp = 0x00007ffc5b6e38e0   rip = 0x00007f6664d60285Found by: stack scanning
14  core-oj.jar + 0x10e9ecrsp = 0x00007ffc5b6e38f0   rip = 0x00007f666410e9ecFound by: stack scanning
15  libart.so + 0x2d2e6rsp = 0x00007ffc5b6e3930   rip = 0x00007f666482d2e6Found by: stack scanning
16  libart.so + 0x3f1dearsp = 0x00007ffc5b6e3940   rip = 0x00007f6664bf1deaFound by: stack scanning
17  libart.so + 0x3f85f8rsp = 0x00007ffc5b6e39d0   rip = 0x00007f6664bf85f8Found by: stack scanning
18  libart.so + 0x3f92darsp = 0x00007ffc5b6e3a10   rip = 0x00007f6664bf92daFound by: stack scanning
19  libart.so + 0x3f8bbersp = 0x00007ffc5b6e3a60   rip = 0x00007f6664bf8bbeFound by: stack scanning
20  libart.so + 0x3f0670rsp = 0x00007ffc5b6e3a90   rip = 0x00007f6664bf0670Found by: stack scanning
21  libart.so + 0x33102rsp = 0x00007ffc5b6e3b90   rip = 0x00007f6664833102Found by: stack scanning
22  libart.so + 0x3489drsp = 0x00007ffc5b6e3ba0   rip = 0x00007f666483489dFound by: stack scanning
23  libart.so + 0x31636rsp = 0x00007ffc5b6e3bb0   rip = 0x00007f6664831636Found by: stack scanning
24  boot.art] + 0x94500rsp = 0x00007ffc5b6e3be8   rip = 0x000000007006c500Found by: stack scanning
25  boot.art] + 0x1f8e00rsp = 0x00007ffc5b6e3cc8   rip = 0x00000000701d0e00Found by: stack scanning
26  libart.so + 0x2d2e6rsp = 0x00007ffc5b6e3d20   rip = 0x00007f666482d2e6Found by: stack scanning
27  libart.so + 0x3f1dearsp = 0x00007ffc5b6e3d30   rip = 0x00007f6664bf1deaFound by: stack scanning
28  libart.so + 0x124b7rsp = 0x00007ffc5b6e3d40   rip = 0x00007f66648124b7Found by: stack scanning
29  libart.so + 0x3f85f8rsp = 0x00007ffc5b6e3dc0   rip = 0x00007f6664bf85f8Found by: stack scanning
30  boot-framework.art] + 0xac86f8rsp = 0x00007ffc5b6e3dd8   rip = 0x0000000070e206f8Found by: stack scanning
......

接下来使用Android NDK里面提供的add2line工具将寄存器地址转换为对应符号。addr2Line要用和自己so和ABI匹配的目录，同时需要使用有符号信息的so（debug生成的）

模拟器采用x86架构，因此使用的add2Line路径为

D:\AndroidSDK\ndk\21.4.7075529\toolchains\x86-4.9\prebuilt\windows-x86_64\bin\i686-linux-android-addr2line.exe

i686-linux-android-addr2line.exe -f -C -e so文件路径 需要转换的堆栈错误信息地址

可以看到，声明了一个指向int类型的指针变量p，初始化为NULL，*p = 10，试图通过空指针去写入数据到内存中，因为p没有指向一个合法的内存地址，操作系统不允许访问该地址，导致程序崩溃。

使用addr2line结合not striped so库能够解析出崩溃的地址等信息。但是需要使用debug版的so文件，让用户上传这个debug版的so有代码泄漏的隐患，并且文件size比较大。

因此在真实场景中，客户端一般是在崩溃之前先上传符号表文件和minidump文件，由服务端通过minidump_stackwalk命令，将dump文件和sym文件合成可读的txt。

breakPad注册信号处理

ExceptionHandler::ExceptionHandler(const MinidumpDescriptor& descriptor,FilterCallback filter,MinidumpCallback callback,void* callback_context,bool install_handler,const int server_fd): filter_(filter),callback_(callback),callback_context_(callback_context),minidump_descriptor_(descriptor),crash_handler_(nullptr) {if (server_fd >= 0)crash_generation_client_.reset(CrashGenerationClient::TryCreate(server_fd));if (!IsOutOfProcess() && !minidump_descriptor_.IsFD() &&!minidump_descriptor_.IsMicrodumpOnConsole())minidump_descriptor_.UpdatePath();#if defined(__ANDROID__)if (minidump_descriptor_.IsMicrodumpOnConsole())logger::initializeCrashLogWriter();
#endifpthread_mutex_lock(&g_handler_stack_mutex_);// Pre-fault the crash context struct. This is to avoid failing due to OOM// if handling an exception when the process ran out of virtual memory.memset(&g_crash_context_, 0, sizeof(g_crash_context_));if (!g_handler_stack_)g_handler_stack_ = new std::vector<ExceptionHandler*>;if (install_handler) {InstallAlternateStackLocked();InstallHandlersLocked();}g_handler_stack_->push_back(this);pthread_mutex_unlock(&g_handler_stack_mutex_);
}

// Runs before crashing: normal context.
// static
bool ExceptionHandler::InstallHandlersLocked() {if (handlers_installed)return false;// Fail if unable to store all the old handlers.for (int i = 0; i < kNumHandledSignals; ++i) {//获取原始信号处理函数（备份）,备份到 old_handlers[] 数组中，后续可以恢复使用if (sigaction(kExceptionSignals[i], nullptr, &old_handlers[i]) == -1)return false;}//构建新的信号处理结构体struct sigaction sa;memset(&sa, 0, sizeof(sa));sigemptyset(&sa.sa_mask);// Mask all exception signals when we're handling one of them.for (int i = 0; i < kNumHandledSignals; ++i)sigaddset(&sa.sa_mask, kExceptionSignals[i]);//设置自定义信号处理函数和标志位sa.sa_sigaction = SignalHandler;sa.sa_flags = SA_ONSTACK | SA_SIGINFO;for (int i = 0; i < kNumHandledSignals; ++i) {if (sigaction(kExceptionSignals[i], &sa, nullptr) == -1) {// At this point it is impractical to back out changes, and so failure to// install a signal is intentionally ignored.}}handlers_installed = true;return true;
}

当特定的信号发生时，SignalHandler 方法就会被调用，SignalHandler 是注册信号时，传入的回调方法。