激情久久久_欧美视频区_成人av免费_不卡视频一二三区_欧美精品在欧美一区二区少妇_欧美一区二区三区的

服務器之家：專注于服務器技術及軟件下載分享
分類導航

PHP教程|ASP.NET教程|Java教程|ASP教程|編程技術|正則表達式|C/C++|IOS|C#|Swift|Android|VB|R語言|JavaScript|易語言|vb.net|

服務器之家 - 編程語言 - Android - Android NDK Crash 定位分析

Android NDK Crash 定位分析

2021-12-30 22:41簡書嘉偉咯 Android

當拿到應用的crash日志,如果是在java層出現了異常,相信大家都知道通過堆棧信息查找到奔潰的代碼,但是如果是在native層出現了問題,面對下面的一堆內存地址,有些小伙伴可能就會覺得無從下手了。

當拿到應用的crash日志,如果是在java層出現了異常,相信大家都知道通過堆棧信息查找到奔潰的代碼,但是如果是在native層出現了問題,面對下面的一堆內存地址,有些小伙伴可能就會覺得無從下手了:

  1. 30597 30597 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
  2. 30597 30597 F DEBUG : Build fingerprint: 'Xiaomi/chiron/chiron:8.0.0/OPR1.170623.027/V10.3.1.0.ODECNXM:user/release-keys'
  3. 30597 30597 F DEBUG : Revision: '0'
  4. 30597 30597 F DEBUG : ABI: 'arm64'
  5. 30597 30597 F DEBUG : pid: 30535, tid: 30535, name: me.linjw.ndkdemo >>> com.me.linjw.ndkdemo <<<
  6. 30597 30597 F DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
  7. 30597 30597 F DEBUG : Abort message: 'Invalid address 0x7ffd3cfac0 passed to free: value not allocated'
  8. 30597 30597 F DEBUG : x0 0000000000000000 x1 0000000000007747 x2 0000000000000006 x3 0000000000000008
  9. 30597 30597 F DEBUG : x4 8000000000808080 x5 8000000000808080 x6 8000000000808080 x7 0000000000000008
  10. 30597 30597 F DEBUG : x8 0000000000000083 x9 d6a0828f4d3c1493 x10 0000000000000000 x11 0000000000000001
  11. 30597 30597 F DEBUG : x12 ffffffffffffffff x13 0000000000000001 x14 003275d83bd3efb5 x15 0000c345d3d41566
  12. 30597 30597 F DEBUG : x16 0000007b582112e8 x17 0000007b581b2d2c x18 0000007ffd3ce5c8 x19 0000000000007747
  13. 30597 30597 F DEBUG : x20 0000000000007747 x21 0000007b5520d000 x22 0000000000000000 x23 0000007b5821c878
  14. 30597 30597 F DEBUG : x24 0000000000000004 x25 0000007b55214c98 x26 0000000000000000 x27 0000000000000001
  15. 30597 30597 F DEBUG : x28 0000000000000001 x29 0000007ffd3cf8c0 x30 0000007b58166e54
  16. 30597 30597 F DEBUG : sp 0000007ffd3cf880 pc 0000007b581b2d34 pstate 0000000060000000
  17. 30597 30597 F DEBUG :
  18. 30597 30597 F DEBUG : backtrace:
  19. 30597 30597 F DEBUG : #00 pc 0000000000069d34 /system/lib64/libc.so (tgkill+8)
  20. 30597 30597 F DEBUG : #01 pc 000000000001de50 /system/lib64/libc.so (abort+88)
  21. 30597 30597 F DEBUG : #02 pc 0000000000025644 /system/lib64/libc.so (__libc_fatal+116)
  22. 30597 30597 F DEBUG : #03 pc 0000000000091204 /system/lib64/libc.so (ifree+812)
  23. 30597 30597 F DEBUG : #04 pc 0000000000091484 /system/lib64/libc.so (je_free+120)
  24. 30597 30597 F DEBUG : #05 pc 000000000000f60c /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/lib/arm64/libnative-lib.so (_Z9willCrashv+80)
  25. 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)
  26. 30597 30597 F DEBUG : #07 pc 000000000000909c /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/oat/arm64/base.o

莫慌,這篇博客就來講講怎么分析這份崩潰日志。

Android NDK Crash 定位分析

信號首先第一個知識點就是信號(signal)機制,它其實是進程間通信的一種方式。在處理ndk crash日志的時候可以大概理解為錯誤碼,它描述了錯誤的大概原因。例如上面的log,可以看到這個程序是因為SIGABRT這個信號奔潰的,它的碼字是6:

  1. 06-04 19:05:38.910 30597 30597 F DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------

我們常見的信號有下面這些:

Android NDK Crash 定位分析

從表里面我們知道SIGABRT信號的觸發原因是通過C函數abort()發送為assert()使用,也就是說它是個斷言失敗,從日志里面我們還能看到abort的信息:

  1. Abort message: 'Invalid address 0x7ffd3cfac0 passed to free: value not allocated'

堆棧分析但是光知道SIGABRT信號我們是很難定位到問題的。所以我們還需要分析下面的堆棧信息,找到對應的代碼:

  1. 30597 30597 F DEBUG : backtrace:
  2. 30597 30597 F DEBUG : #00 pc 0000000000069d34 /system/lib64/libc.so (tgkill+8)
  3. 30597 30597 F DEBUG : #01 pc 000000000001de50 /system/lib64/libc.so (abort+88)
  4. 30597 30597 F DEBUG : #02 pc 0000000000025644 /system/lib64/libc.so (__libc_fatal+116)
  5. 30597 30597 F DEBUG : #03 pc 0000000000091204 /system/lib64/libc.so (ifree+812)
  6. 30597 30597 F DEBUG : #04 pc 0000000000091484 /system/lib64/libc.so (je_free+120)
  7. 30597 30597 F DEBUG : #05 pc 000000000000f60c /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/lib/arm64/libnative-lib.so (_Z9willCrashv+80)
  8. 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)
  9. 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調用了willCrash函數,然后在willCrash函數里面觸發了異常:

  1. 30597 30597 F DEBUG : #05 pc 000000000000f60c /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/lib/arm64/libnative-lib.so (_Z9willCrashv+80)
  2. 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++ 編譯器的函數名修飾

細心的同學可能會有疑問,函數名明明是顯示的_Z9willCrashv,為啥我會說是willCrash?它和下面的Java_com_me_linjw_ndkdemo_MainActivity_callNative有什么區別?

我們可以先來看看源代碼確認下我沒有騙你:

Android NDK Crash 定位分析

那為什么willCrash在編譯之后so里面會變成_Z9willCrashv?這主要是C++編譯器的函數名修飾功能在作怪。由于c++是支持重載的,也就是只要參數不一樣,函數的名字可以相同。

這個重載其實在編譯期就能確定，所以編譯器實現重載的原理是給函數加上修飾符，例如在函數后面拼接上參數類型簡寫，這里_Z9willCrashv最后拼接的v就代表void,說明該函數沒有參數。

也就是說雖然你在代碼里面寫的是同樣的函數名，但是在編譯之后，重載的函數其實就變成了不同名字的不同函數。

解釋完了_Z9willCrashv我們再來說說Java_com_me_linjw_ndkdemo_MainActivity_callNative，為什么它又沒有被修飾呢?原因就在于函數上面的extern "C"，它告訴編譯器將這個函數當做c語言的函數來處理。而c語言是沒有重載這一說的，所以也就不會改變它原本的函數名。

指令偏移地址

然后方法名+號后面的數字是指的什么?方法行數嗎?實際去代碼里面看Java_com_me_linjw_ndkdemo_MainActivity_callNative只有一行代碼,找不到20行，同樣willCrash也沒有80行:

Android NDK Crash 定位分析

這里我們來解釋下+號后面的值的意義。我們都知道c/c++代碼都是需要編譯成二進制文件之后才能運行,而實際上程序就是通過執行二進制文件中的一條條指令來運行的。上面日志中的#06 pc 000000000000f728指的就是出現問題的時候Java_com_me_linjw_ndkdemo_MainActivity_callNative執行到了0x000000000000f728這個地址的指令,而后面的+20指的是這個地址相對方法起始地址的偏移。

說起來可能比較難以理解,這里我們直接通過反匯編libnative-lib.so來幫助理解。ndk提供了objdump工具用于反匯編,由于不同cpu架構的反編譯工具也是不一樣的,大家可以根據需要找到對應的程序進行反匯編:

  1. LinJW@LinJWdeMacBook-Pro  ~/Library/Android/sdk/ndk  find . -name "*objdump"
  2. ./20.0.5594570/toolchains/x86-4.9/prebuilt/darwin-x86_64/bin/i686-linux-android-objdump
  3. ./20.0.5594570/toolchains/x86-4.9/prebuilt/darwin-x86_64/i686-linux-android/bin/objdump
  4. ./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/aarch64-linux-android/bin/objdump
  5. ./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/bin/x86_64-linux-android-objdump
  6. ./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android-objdump
  7. ./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/bin/i686-linux-android-objdump
  8. ./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-objdump
  9. ./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/arm-linux-androideabi/bin/objdump
  10. ./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/x86_64-linux-android/bin/objdump
  11. ./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/i686-linux-android/bin/objdump
  12. ./20.0.5594570/toolchains/x86_64-4.9/prebuilt/darwin-x86_64/bin/x86_64-linux-android-objdump
  13. ./20.0.5594570/toolchains/x86_64-4.9/prebuilt/darwin-x86_64/x86_64-linux-android/bin/objdump
  14. ./20.0.5594570/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-objdump
  15. ./20.0.5594570/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/arm-linux-androideabi/bin/objdump
  16. ./20.0.5594570/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/aarch64-linux-android/bin/objdump
  17. ./20.0.5594570/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-objdump

我這邊使用的是aarch64-linux-android-objdump,命令如下:

  1. aarch64-linux-android-objdump -S ./libnative-lib.so

然后我們搜索Java_com_me_linjw_ndkdemo_MainActivity_callNative找到這個方法的定義:

  1. 000000000000f714 :
  2. f714: d10083ff sub sp, sp, #0x20
  3. f718: a9017bfd stp x29, x30, [sp,#16]
  4. f71c: 910043fd add x29, sp, #0x10
  5. f720: f90007e0 str x0, [sp,#8]
  6. f724: f90003e1 str x1, [sp]
  7. f728: 97ffff0a bl f350 <_Z9willCrashv@plt>
  8. f72c: a9417bfd ldp x29, x30, [sp,#16]
  9. f730: 910083ff add sp, sp, #0x20
  10. f734: d65f03c0 ret
  11. f738: d100c3ff sub sp, sp, #0x30
  12. f73c: a9027bfd stp x29, x30, [sp,#32]
  13. ...

然后我們上面看到的pc 000000000000f728其實指的就是f728這個地址的指令,也就是bl指令,這個指令用于調用子程序,于是我們可以容易猜出這行指令的作用是跳轉到willCrash方法:

  1. f728: 97ffff0a bl f350 <_Z9willCrashv@plt>

而Java_com_me_linjw_ndkdemo_MainActivity_callNative的起始地址為000000000000f714，于是可以計算出000000000000f728相對函數起始地址的偏移為0xf728-0xf714=0x14，而0x14在十進制里面就是20。

addr2line

如果對這些匯編指令比較熟悉的話當然可以分析定位問題,但是一般的安卓程序員可能對這塊比較陌生。所以我們可以用addr2line工具直接定位到源代碼。

我們從下面log可以得到兩個地址000000000000f728、000000000000f60c

  1. 30597 30597 F DEBUG : #05 pc 000000000000f60c /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/lib/arm64/libnative-lib.so (_Z9willCrashv+80)
  2. 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)

使用這個命令的前提是我們要有帶符號的so庫,因為一般情況下打包到apk里面的so都是不帶符號的(可以大概理解成java層的混淆,去掉了符號信息),所以如果直接從apk里面解壓出so,然后使用addr2line會得到下面結果，全是問號:

  1. ??:?

帶符號的so一般會在編譯的過程中生成,所以可以在app/build目錄里面遞歸搜索下,而且不同cpu架構也需要用不同的addr2line,命令如下:

  1. aarch64-linux-android-addr2line -e ./app/build/intermediates/cmake/debug/obj/arm64-v8a/libnative-lib.so 000000000000f728 000000000000f60c

得到結果:

  1. /Users/LinJW/workspace/NdkDemo/app/src/main/cpp/native-lib.cpp:19
  2. /Users/LinJW/workspace/NdkDemo/app/src/main/cpp/native-lib.cpp:13

我們來對比下源碼就能找到崩潰的原因是delete了字符串常量的內存:

Android NDK Crash 定位分析

ndk-stack作為認真看到這里的同學,我必須要獎勵好學的你一個福利,那就是ndk-stack,他也在ndk里面:

  1. NDK目錄/prebuilt/darwin-x86_64/bin/ndk-stack

首先我們將含有native crash的log保存到crash_log.txt用-dump參數出入,然后將所有帶符號的so放到某個目錄下,用-sym參數傳入:

  1. ndk-stack -sym ./app/build/intermediates/cmake/debug/obj/arm64-v8a/ -dump ~/Downloads/crash_log.txt

然后它就會對native堆棧使用addr2line和目錄下的so去轉換,最終輸出帶符號的堆棧信息:

  1. ********* Crash dump: **********
  2. Build fingerprint: 'Xiaomi/chiron/chiron:8.0.0/OPR1.170623.027/V10.3.1.0.ODECNXM:user/release-keys'
  3. Abort message: 'Invalid address 0x7ffd3cfac0 passed to free: value not allocated'
  4. #00 0x0000000000069d34 /system/lib64/libc.so (tgkill+8)
  5. #01 0x000000000001de50 /system/lib64/libc.so (abort+88)
  6. #02 0x0000000000025644 /system/lib64/libc.so (__libc_fatal+116)
  7. #03 0x0000000000091204 /system/lib64/libc.so (ifree+812)
  8. #04 0x0000000000091484 /system/lib64/libc.so (je_free+120)
  9. #05 0x000000000000f60c /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/lib/arm64/libnative-lib.so (_Z9willCrashv+80)
  10. willCrash()
  11. /Users/LinJW/workspace/NdkDemo/app/src/main/cpp/native-lib.cpp:13:5
  12. #06 0x000000000000f728 /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/lib/arm64/libnative-lib.so (Java_com_me_linjw_ndkdemo_MainActivity_callNative+2
  13. 0)
  14. Java_com_cvte_tv_ndkdemo_MainActivity_callNative
  15. /Users/LinJW/workspace/NdkDemo/app/src/main/cpp/native-lib.cpp:19:5
  16. #07 0x000000000000909c /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/oat/arm64/base.odex (offset 0x9000)

ndk-stack在開始解析 logcat 輸出時將查找第一行星號,所以拷貝的時候記得這行不能缺少:

  1. *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

當然通常情況下我們直接將logcat出來的所有日志傳給它就好，它會自動根據星號行識別出native堆棧:

  1. adb logcat | ndk-stack路徑 -sym 存放帶符號so庫目錄的路徑

原文地址：https://www.jianshu.com/p/25ddc3055214

延伸 · 閱讀

精彩推薦
主站蜘蛛池模板： 色妞视频男女视频 | 久久久国产精品电影 | 中文字幕在线成人 | 日本一区二区精品视频 | 日韩在线视频在线观看 | 国产一级伦理片 | 麻豆传传媒久久久爱 | 五月婷婷第四色 | 欧美一区二区黄色 | 99国产精品国产免费观看 | 欧美成年性h版影视中文字幕 | 偷偷操偷偷操 | 亚洲成人国产综合 | 国内精品久久久久久久久久 | 国产一级www | 久久精品99国产国产精 | 99视频网 | 欧美国产一区二区三区 | 九九热播视频 | 欧美成人高清视频 | 国产色视频在线观看免费 | 在线成人www免费观看视频 | 成人午夜视频免费在线观看 | 欧美国产精品一区二区 | 色999国产 | 深夜免费福利视频 | 小雪奶水翁胀公吸小说最新章节 | 国产午夜亚洲精品 | 午夜a狂野欧美一区二区 | 久久久久亚洲a | 羞羞色在线观看 | 久久久国产精品免费观看 | 久久国产精| 精品欧美一区二区精品久久 | 亚洲精品tv久久久久久久久久 | 国产精品一区二区三区在线 | 国产福利不卡一区二区三区 | 亚洲无限资源 | 精品一区二区三区网站 | 把娇妻调教成暴露狂 | 久久久久亚洲视频 |