當(dāng)拿到應(yīng)用的crash日志,如果是在java層出現(xiàn)了異常,相信大家都知道通過堆棧信息查找到奔潰的代碼,但是如果是在native層出現(xiàn)了問題,面對(duì)下面的一堆內(nèi)存地址,有些小伙伴可能就會(huì)覺得無從下手了:
30597 30597 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
30597 30597 F DEBUG : Build fingerprint: 'Xiaomi/chiron/chiron:8.0.0/OPR1.170623.027/V10.3.1.0.ODECNXM:user/release-keys'
30597 30597 F DEBUG : Revision: '0'
30597 30597 F DEBUG : ABI: 'arm64'
30597 30597 F DEBUG : pid: 30535, tid: 30535, name: me.linjw.ndkdemo >>> com.me.linjw.ndkdemo <<<
30597 30597 F DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
30597 30597 F DEBUG : Abort message: 'Invalid address 0x7ffd3cfac0 passed to free: value not allocated'
30597 30597 F DEBUG : x0 0000000000000000 x1 0000000000007747 x2 0000000000000006 x3 0000000000000008
30597 30597 F DEBUG : x4 8000000000808080 x5 8000000000808080 x6 8000000000808080 x7 0000000000000008
30597 30597 F DEBUG : x8 0000000000000083 x9 d6a0828f4d3c1493 x10 0000000000000000 x11 0000000000000001
30597 30597 F DEBUG : x12 ffffffffffffffff x13 0000000000000001 x14 003275d83bd3efb5 x15 0000c345d3d41566
30597 30597 F DEBUG : x16 0000007b582112e8 x17 0000007b581b2d2c x18 0000007ffd3ce5c8 x19 0000000000007747
30597 30597 F DEBUG : x20 0000000000007747 x21 0000007b5520d000 x22 0000000000000000 x23 0000007b5821c878
30597 30597 F DEBUG : x24 0000000000000004 x25 0000007b55214c98 x26 0000000000000000 x27 0000000000000001
30597 30597 F DEBUG : x28 0000000000000001 x29 0000007ffd3cf8c0 x30 0000007b58166e54
30597 30597 F DEBUG : sp 0000007ffd3cf880 pc 0000007b581b2d34 pstate 0000000060000000
30597 30597 F DEBUG :
30597 30597 F DEBUG : backtrace:
30597 30597 F DEBUG : #00 pc 0000000000069d34 /system/lib64/libc.so (tgkill+8)
30597 30597 F DEBUG : #01 pc 000000000001de50 /system/lib64/libc.so (abort+88)
30597 30597 F DEBUG : #02 pc 0000000000025644 /system/lib64/libc.so (__libc_fatal+116)
30597 30597 F DEBUG : #03 pc 0000000000091204 /system/lib64/libc.so (ifree+812)
30597 30597 F DEBUG : #04 pc 0000000000091484 /system/lib64/libc.so (je_free+120)
30597 30597 F DEBUG : #05 pc 000000000000f60c /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/lib/arm64/libnative-lib.so (_Z9willCrashv+80)
30597 30597 F DEBUG : #06 pc 000000000000f728 /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/lib/arm64/libnative-lib.so (Java_com_me_linjw_ndkdemo_MainActivity_callNative+20)
30597 30597 F DEBUG : #07 pc 000000000000909c /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/oat/arm64/base.odex (offset 0x9000)
莫慌,這篇博客就來講講怎么分析這份崩潰日志。
信號(hào)
首先第一個(gè)知識(shí)點(diǎn)就是信號(hào)(signal)機(jī)制,它其實(shí)是進(jìn)程間通信的一種方式。在處理ndk crash日志的時(shí)候可以大概理解為錯(cuò)誤碼,它描述了錯(cuò)誤的大概原因。例如上面的log,可以看到這個(gè)程序是因?yàn)镾IGABRT這個(gè)信號(hào)奔潰的,它的碼字是6:
06-04 19:05:38.910 30597 30597 F DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
我們常見的信號(hào)有下面這些:
| 信號(hào) | 碼值 | 描述 |
|---|---|---|
| SIGILL | 4 | 非法指令，例如損壞的可執(zhí)行文件或代碼區(qū)損壞 |
| SIGABRT | 6 | 通過C函數(shù)abort()發(fā)送；為assert()使用 |
| SIGBUS | 7 | 不存在的物理地址，更多為硬件或系統(tǒng)引起 |
| SIGFPE | 8 | 浮點(diǎn)數(shù)運(yùn)算錯(cuò)誤，如除0操作 |
| SIGKILL | 9 | 迅速完全終止進(jìn)程；不能被捕獲 |
| SIGSEGV | 11 | 段地址錯(cuò)誤，例如空指針、野指針、數(shù)組越界等 |
從表里面我們知道SIGABRT信號(hào)的觸發(fā)原因是通過C函數(shù)abort()發(fā)送為assert()使用,也就是說它是個(gè)斷言失敗,從日志里面我們還能看到abort的信息:
Abort message: 'Invalid address 0x7ffd3cfac0 passed to free: value not allocated'
堆棧分析
但是光知道SIGABRT信號(hào)我們是很難定位到問題的。所以我們還需要分析下面的堆棧信息,找到對(duì)應(yīng)的代碼:
30597 30597 F DEBUG : backtrace:
30597 30597 F DEBUG : #00 pc 0000000000069d34 /system/lib64/libc.so (tgkill+8)
30597 30597 F DEBUG : #01 pc 000000000001de50 /system/lib64/libc.so (abort+88)
30597 30597 F DEBUG : #02 pc 0000000000025644 /system/lib64/libc.so (__libc_fatal+116)
30597 30597 F DEBUG : #03 pc 0000000000091204 /system/lib64/libc.so (ifree+812)
30597 30597 F DEBUG : #04 pc 0000000000091484 /system/lib64/libc.so (je_free+120)
30597 30597 F DEBUG : #05 pc 000000000000f60c /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/lib/arm64/libnative-lib.so (_Z9willCrashv+80)
30597 30597 F DEBUG : #06 pc 000000000000f728 /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/lib/arm64/libnative-lib.so (Java_com_me_linjw_ndkdemo_MainActivity_callNative+20)
30597 30597 F DEBUG : #07 pc 000000000000909c /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/oat/arm64/base.odex (offset 0x9000)
從這里我們可以分析到libnative-lib.so里面的Java_com_me_linjw_ndkdemo_MainActivity_callNative調(diào)用了willCrash函數(shù),然后在willCrash函數(shù)里面觸發(fā)了異常:
30597 30597 F DEBUG : #05 pc 000000000000f60c /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/lib/arm64/libnative-lib.so (_Z9willCrashv+80)
30597 30597 F DEBUG : #06 pc 000000000000f728 /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/lib/arm64/libnative-lib.so (Java_com_me_linjw_ndkdemo_MainActivity_callNative+20)
C++ 編譯器的函數(shù)名修飾
細(xì)心的同學(xué)可能會(huì)有疑問,函數(shù)名明明是顯示的_Z9willCrashv,為啥我會(huì)說是willCrash？它和下面的Java_com_me_linjw_ndkdemo_MainActivity_callNative有什么區(qū)別？
我們可以先來看看源代碼確認(rèn)下我沒有騙你:
那為什么willCrash在編譯之后so里面會(huì)變成_Z9willCrashv?這主要是C++編譯器的函數(shù)名修飾功能在作怪。由于c++是支持重載的,也就是只要參數(shù)不一樣,函數(shù)的名字可以相同。
這個(gè)重載其實(shí)在編譯期就能確定，所以編譯器實(shí)現(xiàn)重載的原理是給函數(shù)加上修飾符，例如在函數(shù)后面拼接上參數(shù)類型簡(jiǎn)寫，這里_Z9willCrashv最后拼接的v就代表void,說明該函數(shù)沒有參數(shù)。
也就是說雖然你在代碼里面寫的是同樣的函數(shù)名，但是在編譯之后，重載的函數(shù)其實(shí)就變成了不同名字的不同函數(shù)。
解釋完了_Z9willCrashv我們?cè)賮碚f說Java_com_me_linjw_ndkdemo_MainActivity_callNative，為什么它又沒有被修飾呢？原因就在于函數(shù)上面的extern "C"，它告訴編譯器將這個(gè)函數(shù)當(dāng)做c語言的函數(shù)來處理。而c語言是沒有重載這一說的，所以也就不會(huì)改變它原本的函數(shù)名。
指令偏移地址
然后方法名+號(hào)后面的數(shù)字是指的什么？方法行數(shù)嗎?實(shí)際去代碼里面看Java_com_me_linjw_ndkdemo_MainActivity_callNative只有一行代碼,找不到20行，同樣willCrash也沒有80行:
這里我們來解釋下+號(hào)后面的值的意義。我們都知道c/c++代碼都是需要編譯成二進(jìn)制文件之后才能運(yùn)行,而實(shí)際上程序就是通過執(zhí)行二進(jìn)制文件中的一條條指令來運(yùn)行的。上面日志中的#06 pc 000000000000f728指的就是出現(xiàn)問題的時(shí)候Java_com_me_linjw_ndkdemo_MainActivity_callNative執(zhí)行到了0x000000000000f728這個(gè)地址的指令,而后面的+20指的是這個(gè)地址相對(duì)方法起始地址的偏移。
說起來可能比較難以理解,這里我們直接通過反匯編libnative-lib.so來幫助理解。ndk提供了objdump工具用于反匯編,由于不同cpu架構(gòu)的反編譯工具也是不一樣的,大家可以根據(jù)需要找到對(duì)應(yīng)的程序進(jìn)行反匯編:
LinJW@LinJWdeMacBook-Pro ~/Library/Android/sdk/ndk find . -name "*objdump"
./20.0.5594570/toolchains/x86-4.9/prebuilt/darwin-x86_64/bin/i686-linux-android-objdump
./20.0.5594570/toolchains/x86-4.9/prebuilt/darwin-x86_64/i686-linux-android/bin/objdump
./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/aarch64-linux-android/bin/objdump
./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/bin/x86_64-linux-android-objdump
./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android-objdump
./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/bin/i686-linux-android-objdump
./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-objdump
./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/arm-linux-androideabi/bin/objdump
./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/x86_64-linux-android/bin/objdump
./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/i686-linux-android/bin/objdump
./20.0.5594570/toolchains/x86_64-4.9/prebuilt/darwin-x86_64/bin/x86_64-linux-android-objdump
./20.0.5594570/toolchains/x86_64-4.9/prebuilt/darwin-x86_64/x86_64-linux-android/bin/objdump
./20.0.5594570/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-objdump
./20.0.5594570/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/arm-linux-androideabi/bin/objdump
./20.0.5594570/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/aarch64-linux-android/bin/objdump
./20.0.5594570/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-objdump
我這邊使用的是aarch64-linux-android-objdump,命令如下:
aarch64-linux-android-objdump -S ./libnative-lib.so
然后我們搜索Java_com_me_linjw_ndkdemo_MainActivity_callNative找到這個(gè)方法的定義:
000000000000f714 <Java_com_me_linjw_ndkdemo_MainActivity_callNative@@Base>:
f714: d10083ff sub sp, sp, #0x20
f718: a9017bfd stp x29, x30, [sp,#16]
f71c: 910043fd add x29, sp, #0x10
f720: f90007e0 str x0, [sp,#8]
f724: f90003e1 str x1, [sp]
f728: 97ffff0a bl f350 <_Z9willCrashv@plt>
f72c: a9417bfd ldp x29, x30, [sp,#16]
f730: 910083ff add sp, sp, #0x20
f734: d65f03c0 ret
f738: d100c3ff sub sp, sp, #0x30
f73c: a9027bfd stp x29, x30, [sp,#32]
...
然后我們上面看到的pc 000000000000f728其實(shí)指的就是f728這個(gè)地址的指令,也就是bl指令,這個(gè)指令用于調(diào)用子程序,于是我們可以容易猜出這行指令的作用是跳轉(zhuǎn)到willCrash方法:
f728: 97ffff0a bl f350 <_Z9willCrashv@plt>
而Java_com_me_linjw_ndkdemo_MainActivity_callNative的起始地址為000000000000f714，于是可以計(jì)算出000000000000f728相對(duì)函數(shù)起始地址的偏移為0xf728-0xf714=0x14，而0x14在十進(jìn)制里面就是20。
addr2line
如果對(duì)這些匯編指令比較熟悉的話當(dāng)然可以分析定位問題,但是一般的安卓程序員可能對(duì)這塊比較陌生。所以我們可以用addr2line工具直接定位到源代碼。
我們從下面log可以得到兩個(gè)地址000000000000f728、000000000000f60c
30597 30597 F DEBUG : #05 pc 000000000000f60c /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/lib/arm64/libnative-lib.so (_Z9willCrashv+80)
30597 30597 F DEBUG : #06 pc 000000000000f728 /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/lib/arm64/libnative-lib.so (Java_com_me_linjw_ndkdemo_MainActivity_callNative+20)
使用這個(gè)命令的前提是我們要有帶符號(hào)的so庫(kù),因?yàn)橐话闱闆r下打包到apk里面的so都是不帶符號(hào)的(可以大概理解成java層的混淆,去掉了符號(hào)信息),所以如果直接從apk里面解壓出so,然后使用addr2line會(huì)得到下面結(jié)果，全是問號(hào):
??:?
帶符號(hào)的so一般會(huì)在編譯的過程中生成,所以可以在app/build目錄里面遞歸搜索下,而且不同cpu架構(gòu)也需要用不同的addr2line,命令如下:
aarch64-linux-android-addr2line -e ./app/build/intermediates/cmake/debug/obj/arm64-v8a/libnative-lib.so 000000000000f728 000000000000f60c
得到結(jié)果:
/Users/LinJW/workspace/NdkDemo/app/src/main/cpp/native-lib.cpp:19
/Users/LinJW/workspace/NdkDemo/app/src/main/cpp/native-lib.cpp:13
我們來對(duì)比下源碼就能找到崩潰的原因是delete了字符串常量的內(nèi)存:
ndk-stack
作為認(rèn)真看到這里的同學(xué),我必須要獎(jiǎng)勵(lì)好學(xué)的你一個(gè)福利,那就是ndk-stack,他也在ndk里面:
NDK目錄/prebuilt/darwin-x86_64/bin/ndk-stack
首先我們將含有native crash的log保存到crash_log.txt用-dump參數(shù)出入,然后將所有帶符號(hào)的so放到某個(gè)目錄下,用-sym參數(shù)傳入:
ndk-stack -sym ./app/build/intermediates/cmake/debug/obj/arm64-v8a/ -dump ~/Downloads/crash_log.txt
然后它就會(huì)對(duì)native堆棧使用addr2line和目錄下的so去轉(zhuǎn)換,最終輸出帶符號(hào)的堆棧信息:
********* Crash dump: **********
Build fingerprint: 'Xiaomi/chiron/chiron:8.0.0/OPR1.170623.027/V10.3.1.0.ODECNXM:user/release-keys'
Abort message: 'Invalid address 0x7ffd3cfac0 passed to free: value not allocated'
#00 0x0000000000069d34 /system/lib64/libc.so (tgkill+8)
#01 0x000000000001de50 /system/lib64/libc.so (abort+88)
#02 0x0000000000025644 /system/lib64/libc.so (__libc_fatal+116)
#03 0x0000000000091204 /system/lib64/libc.so (ifree+812)
#04 0x0000000000091484 /system/lib64/libc.so (je_free+120)
#05 0x000000000000f60c /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/lib/arm64/libnative-lib.so (_Z9willCrashv+80)
willCrash()
/Users/LinJW/workspace/NdkDemo/app/src/main/cpp/native-lib.cpp:13:5
#06 0x000000000000f728 /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/lib/arm64/libnative-lib.so (Java_com_me_linjw_ndkdemo_MainActivity_callNative+2
0)
Java_com_cvte_tv_ndkdemo_MainActivity_callNative
/Users/LinJW/workspace/NdkDemo/app/src/main/cpp/native-lib.cpp:19:5
#07 0x000000000000909c /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/oat/arm64/base.odex (offset 0x9000)
ndk-stack在開始解析 logcat 輸出時(shí)將查找第一行星號(hào),所以拷貝的時(shí)候記得這行不能缺少:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
當(dāng)然通常情況下我們直接將logcat出來的所有日志傳給它就好，它會(huì)自動(dòng)根據(jù)星號(hào)行識(shí)別出native堆棧:
adb logcat | ndk-stack路徑 -sym 存放帶符號(hào)so庫(kù)目錄的路徑
