監控Java層和JNI Native層Crash，分析.so庫報錯的堆疊資訊

監控Java層和JNI Native層Crash，分析.so庫報錯的堆疊資訊

Crash（應用崩潰）是由於程式碼異常而導致 App 非正常退出，導致應用程式無法繼續使用，所有工作都停止的現象。發生 Crash 後需要重新啟動應用（有些情況會自動重啟），而且不管應用在開發階段做得多麼優秀，也無法避免 Crash 發生，特別是在Android 系統中，系統碎片化嚴重、各 ROM 之間的差異，甚至系統Bug，都可能會導致Crash的發生。在 Android 應用中發生的 Crash 有兩種型別，Java 層的 Crash 和 Native 層 Crash。這兩種Crash 的監控和獲取堆疊資訊有所不同。

1、Java Crash

Java的Crash監控非常簡單，Java中的Thread定義了一個介面： UncaughtExceptionHandler ；用於處理未捕獲的異常導致執行緒的終止（注意：catch了的是捕獲不到的），當我們的應用crash的時候，就會走UncaughtExceptionHandler.uncaughtException ，在該方法中可以獲取到異常的資訊，我們通過Thread.setDefaultUncaughtExceptionHandler 該方法來設定執行緒的預設異常處理器，我們可以將異常資訊儲存到本地或者是上傳到伺服器，方便我們快速的定位問題。

public class JavaCrashHandler implements Thread.UncaughtExceptionHandler {

    private static final String FILE_NAME_SUFFIX = ".log";
    private static Thread.UncaughtExceptionHandler mDefaultCrashHandler;
    private static Context mContext;

    private JavaCrashHandler() {
    }

    public static void init(@NonNull Context context) {
        // 預設為：RuntimeInit#KillApplicationHandler
        mDefaultCrashHandler = Thread.getDefaultUncaughtExceptionHandler();
        mContext = context.getApplicationContext();
        Thread.setDefaultUncaughtExceptionHandler(new JavaCrashHandler());
    }

    @Override
    public void uncaughtException(@NonNull Thread thread, @NonNull Throwable throwable) {
        try {
            // 自行處理：儲存本地
            File file = dealException(thread, throwable);
            // 上傳伺服器
            // ......
        } catch (Exception e1) {
            e1.printStackTrace();
        } finally {
            // 交給系統預設程式處理
            if (mDefaultCrashHandler != null) {
                mDefaultCrashHandler.uncaughtException(thread, throwable);
            }
        }
    }

    private File dealException(Thread thread, Throwable throwable) {
        String time = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date());
        File crashFolder = new File(mContext.getExternalCacheDir().getAbsoluteFile(), CrashMonitor.DEFAULT_JAVA_CRASH_FOLDER_NAME);
        if (!crashFolder.exists()) {
            crashFolder.mkdirs();
        }
        File crashFile = new File(crashFolder, time + FILE_NAME_SUFFIX);
        try {
            // 往檔案中寫入資料
            PrintWriter pw = new PrintWriter(new BufferedWriter(new FileWriter(crashFile)));
            pw.println(time);
            pw.println(thread);
            pw.println(getPhoneInfo());
            throwable.printStackTrace(pw);
            // 寫入crash堆疊
            pw.close();
        } catch (IOException ex) {
            ex.printStackTrace();
        }
        return crashFile;
    }

    private String getPhoneInfo() {
        PackageManager pm = mContext.getPackageManager();
        PackageInfo pi = null;
        StringBuilder sb = new StringBuilder();

        try {
            pi = pm.getPackageInfo(mContext.getPackageName(), PackageManager.GET_ACTIVITIES);

            // App版本
            sb.append("App Version: ");
            sb.append(pi.versionName);
            sb.append("_");
            sb.append(pi.versionCode + "\n");
        } catch (PackageManager.NameNotFoundException e) {
            e.printStackTrace();
        }

        // Android版本號
        sb.append("OS Version: ");
        sb.append(Build.VERSION.RELEASE);
        sb.append("_");
        sb.append(Build.VERSION.SDK_INT + "\n");

        // 手機制造商
        sb.append("Vendor: ");
        sb.append(Build.MANUFACTURER + "\n");

        // 手機型號
        sb.append("Model: ");
        sb.append(Build.MODEL + "\n");

        // CPU架構
        sb.append("CPU: ");
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
            sb.append(Arrays.toString(Build.SUPPORTED_ABIS));
        } else {
            sb.append(Build.CPU_ABI);
        }

        return sb.toString();
    }
}

---

2、NDK Crash (Native、JNI)

相對於Java的Crash，NDK的錯誤無疑更加讓人頭疼，特別是對初學NDK的同學，不說監控，就算是錯誤堆疊都不知道怎麼看。

2.1、Linux訊號機制

訊號機制是Linux程式間通訊的一種重要方式，Linux訊號一方面用於正常的程式間通訊和同步，另一方面它還負責監控系統異常及中斷。當應用程式執行異常時，Linux核心將產生錯誤訊號並通知當前程式。當前程式在接收到該錯誤訊號後，可以有三種不同的處理方式。

• 忽略該訊號；
• 捕捉該訊號並執行對應的訊號處理函式（訊號處理程式）；
• 執行該訊號的預設操作（如終止程式）；

當Linux應用程式在執行時發生嚴重錯誤，一般會導致程式崩潰。其中，Linux專門提供了一類crash訊號，在程式接收到此類訊號時，預設操作是將崩潰的現場資訊記錄到核心檔案，然後終止程式。
常見崩潰訊號列表：

訊號	描述
SIGSEGV	記憶體引用無效。
SIGBUS	訪問記憶體物件的未定義部分。
SIGFPE	算術運算錯誤，除以零。
SIGILL	非法指令，如執行垃圾或特權指令。
SIGSYS	糟糕的系統呼叫。
SIGXCPU	超過CPU時間限制。
SIGXFSZ	檔案大小限制。

一般的出現崩潰訊號，Android系統預設預設操作是直接退出我們的程式。但是系統允許我們給某一個程式的某一個特定訊號註冊一個相應的處理函式（signal），即對該訊號的預設處理動作進行修改。因此NDK Crash的監控可以採用這種訊號機制，捕獲崩潰訊號執行我們自己的訊號處理函式從而捕獲NDK Crash。

2.2、墓碑檔案(tombstones)

Android本機程式本質上就是一個Linux程式，當它在執行時發生嚴重錯誤，也會導致程式崩潰，然後產生一個記錄崩潰的現場資訊的檔案，而這個檔案在Android系統中就是 tombstones 墓碑檔案。

此處瞭解即可，普通應用無許可權讀取墓碑檔案，墓碑檔案位於路徑/data/tombstones/下。解析墓碑檔案與後面的breakpad都可使用 addr2line 工具。

2.3、BreakPad

Google breakpad是一個跨平臺的崩潰轉儲和分析框架和工具集合，其開源地址是：https://github.com/google/breakpad。breakpad在Linux中的實現就是藉助了Linux訊號捕獲機制實現的。因為其實現為C++，因此在Android中使用，必須藉助NDK工具。

2.4、Native Crash監控

將Breakpad原始碼下載解壓，首先檢視README.ANDROID檔案。

按照文件中的介紹，如果我們使用Android.mk 非常簡單就能夠引入到我們工程中，但是目前NDK預設的構建工具為：CMake，因此我們做一次移植。檢視android/google_breakpad/Android.mk

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/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) # 注意這個目錄

# 匯出標頭檔案
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_C_INCLUDES)

# 使用android ndk中的日誌庫log
LOCAL_EXPORT_LDLIBS     := -llog

# 編譯static靜態庫-》類似java的jar包
include $(BUILD_STATIC_LIBRARY)

注意：mk檔案中 LOCAL_C_INCLUDES 的 LSS_PATH 是個坑

對照Android.mk檔案，我們在自己專案的cpp(工程中C/C++原始碼)目錄下建立breakpad目錄，並將下載的breakpad原始碼根目錄下的src目錄全部複製到我們的專案中：

接下來在breakpad目錄下建立CMakeLists.txt檔案:

cmake_minimum_required(VERSION 3.4.1)

#引入breakpad的標頭檔案（api的定義）
include_directories(breakpad/src breakpad/src/common/android/include)

#引入breakpad的cmakelist，執行並生成libbreakpad.a (api的實現，類似java的jar包)
add_subdirectory(breakpad)

add_library(crash_monitor SHARED native_crash_monitor.cpp)

target_link_libraries(crash_monitor
        breakpad #引入breakpad的庫檔案(api的實現)
        log)

在cpp目錄下（breakpad同級）還有一個CMakeList.txt檔案，它的內容是：

cmake_minimum_required(VERSION 3.4.1)

#引入breakpad的標頭檔案（api的定義）
include_directories(breakpad/src breakpad/src/common/android/include)

#引入breakpad的cmakelist，執行並生成libbreakpad.a (api的實現，類似java的jar包)
add_subdirectory(breakpad)

add_library(crash_monitor SHARED native_crash_monitor.cpp)

target_link_libraries(crash_monitor
        breakpad #引入breakpad的庫檔案(api的實現)
        log)

此時執行編譯，會在 #include “third_party/lss/linux_syscall_support.h” 報錯，無法找到標頭檔案。此檔案從：https://chromium.googlesource.com/external/linux-syscall-support/+/refs/heads/master 下載（需要翻牆）放到工程對應目錄即可。

native_crash_monitor.cpp 原始檔中的實現為：

#include <jni.h>
#include <android/log.h>
#include <client/linux/handler/minidump_descriptor.h>
#include <client/linux/handler/exception_handler.h>

extern "C"
JNIEXPORT void JNICALL
Java_com_aaa_crashmonitor_CrashMonitor_testNativeCrash(JNIEnv *env, jclass clazz) {
    __android_log_print(ANDROID_LOG_ERROR, "testNativeCrash", "往指向空地址的指標裡存值");
    int *p = NULL;
    *p = 10;
}

bool
DumpCallback(const google_breakpad::MinidumpDescriptor &descriptor, void *context, bool succeeded) {
    __android_log_print(ANDROID_LOG_ERROR, "ndk_crash", "Dump path: %s", descriptor.path());
    // 如果回撥返回true，Breakpad將把異常視為已完全處理，禁止任何其他處理程式收到異常通知。
    // 如果回撥返回false，Breakpad會將異常視為未處理，並允許其他處理程式處理它。
    return false;
}

extern "C"
JNIEXPORT void JNICALL
Java_com_aaa_crashmonitor_CrashMonitor_initNativeCrashMonitor(JNIEnv *env, jclass clazz,
                                                              jstring path_) {
    const char *path = env->GetStringUTFChars(path_, 0);
    __android_log_print(ANDROID_LOG_DEBUG, "initNativeCrashMonitor", "crash堆疊儲存路徑=%s ", path);
    // 開啟crash監控
    google_breakpad::MinidumpDescriptor descriptor(path);
    static google_breakpad::ExceptionHandler eh(descriptor, NULL, DumpCallback, NULL, true, -1);
    __android_log_print(ANDROID_LOG_DEBUG, "initNativeCrashMonitor", "breakpad已開啟");
    env->ReleaseStringUTFChars(path_, path);
}

注意JNI方法的方法名對應了java類，建立Java原始檔：

public class CrashMonitor {

    public static final String DEFAULT_JAVA_CRASH_FOLDER_NAME = "java_crash";
    public static final String DEFAULT_NATIVE_CRASH_FOLDER_NAME = "native_crash";

    static {
        System.loadLibrary("crash_monitor");
    }

    public static void initAll(Context context) {
        initJavaCrashMonitor(context);
        initNativeCrashMonitor(context);
    }

    public static void initJavaCrashMonitor(Context context) {
        JavaCrashHandler.init(context.getApplicationContext());
    }

    public static void initNativeCrashMonitor(Context context) {
        Context appContext = context.getApplicationContext();
        File crashFile = new File(appContext.getExternalCacheDir(), DEFAULT_NATIVE_CRASH_FOLDER_NAME);
        if (!crashFile.exists()) {
            crashFile.mkdirs();
        }
        initNativeCrashMonitor(crashFile.getAbsolutePath());
    }

    public static native void initNativeCrashMonitor(String path);

    public static native void testNativeCrash();

    public static void testJavaCrash() {
        int a = 1 / 0;
    }
}

此時，如果出現NDK Crash，會在我們指定的目錄：/sdcard/Android/data/com.aaa.crashmonitor/cache/native_crash 下生成NDK Crash資訊檔案。

2.5、Native Crash分析

採集到的Crash資訊記錄在minidump檔案中。minidump是由微軟開發的用於崩潰上傳的檔案格式。我們可以將此檔案上傳到伺服器完成上報，但是此檔案沒有可讀性可言，要將檔案解析為可讀的崩潰堆疊需要按照breakpad文件編譯 minidump_stackwalk 工具，而Windows系統編譯個人不會。不過好在，無論你是 Mac、windows還是ubuntu在 Android Studio 的安裝目錄下的 bin\lldb\bin 裡面就存在一個對應平臺的 minidump_stackwalk 。

使用這裡的工具執行：

minidump_stackwalk xxxx.dump > native_crash.txt

開啟 native_crash.txt 內容為：

Operating system: Android
                  0.0.0 Linux 4.14.112+ #1 SMP PREEMPT Fri Sep 13 21:20:42 UTC 2019 i686
CPU: x86 // abi型別
     GenuineIntel family 6 model 31 stepping 1
     4 CPUs

GPU: UNKNOWN

Crash reason:  SIGSEGV // 記憶體引用無效訊號
Crash address: 0x0
Process uptime: not available

Thread 0 (crashed) // crashed：出現crash的執行緒
 0  libcrash_monitor.so + 0x1e944 // crash的so與暫存器資訊
    eip = 0xc7b26944   esp = 0xffbfdaf0   ebp = 0xffbfdb28   ebx = 0xc7ba04b8
    esi = 0xc7b8123c   edi = 0xc7b8124c   eax = 0x00000036   ecx = 0x00000000
    edx = 0x00000004   efl = 0x00010246
    Found by: given as instruction pointer in context
 1  libart.so + 0x144f68
    eip = 0xed51af68   esp = 0xffbfdb30   ebp = 0xffbfdb50
    Found by: previous frame's frame pointer

接下來使用 Android NDK 裡面提供的 addr2line 工具將暫存器地址轉換為對應符號。addr2line 要用和自己 so 的 ABI 匹配的目錄，同時需要使用有符號資訊的so(一般debug的就有)。

因為我使用的是模擬器x86架構，因此addr2line位於：Android\Sdk\ndk\20.0.5594570\toolchains\x86-4.9\prebuilt\windows-x86_64\bin\i686-linux-android-addr2line.exe

i686-linux-android-addr2line.exe -f -C -e libcrash_monitor.so 0x1e934