AndroidNDKCrash定位分析

当拿到应用的crash日志,如果是在java层出现了异常,相信大家都知道通过堆栈信息查找到奔溃的代码,但是如果是在native层出现了问题,面对下面的一堆内存地址,有些小伙伴可能就会觉得无从下手了:

目前创新互联建站已为成百上千家的企业提供了网站建设、域名、网站空间、网站运营、企业网站设计、巨鹿网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。

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

莫慌,这篇博客就来讲讲怎么分析这份崩溃日志。

信号首先第一个知识点就是信号(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 -------- 
    2.

我们常见的信号有下面这些:

从表里面我们知道SIGABRT信号的触发原因是通过C函数abort()发送为assert()使用,也就是说它是个断言失败,从日志里面我们还能看到abort的信息:

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

堆栈分析但是光知道SIGABRT信号我们是很难定位到问题的。所以我们还需要分析下面的堆栈信息,找到对应的代码:

 
 
 
 
    
  
  
  
  
  1. 30597 30597 F DEBUG   : backtrace: 
    2. 
  
  
  
  
  2. 30597 30597 F DEBUG   :     #00 pc 0000000000069d34  /system/lib64/libc.so (tgkill+8) 
    3. 
  
  
  
  
  3. 30597 30597 F DEBUG   :     #01 pc 000000000001de50  /system/lib64/libc.so (abort+88) 
    4. 
  
  
  
  
  4. 30597 30597 F DEBUG   :     #02 pc 0000000000025644  /system/lib64/libc.so (__libc_fatal+116) 
    5. 
  
  
  
  
  5. 30597 30597 F DEBUG   :     #03 pc 0000000000091204  /system/lib64/libc.so (ifree+812) 
    6. 
  
  
  
  
  6. 30597 30597 F DEBUG   :     #04 pc 0000000000091484  /system/lib64/libc.so (je_free+120) 
    7. 
  
  
  
  
  7. 30597 30597 F DEBUG   :     #05 pc 000000000000f60c  /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/lib/arm64/libnative-lib.so (_Z9willCrashv+80) 
    8. 
  
  
  
  
  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. 
  
  
  
  
  9. 30597 30597 F DEBUG   :     #07 pc 000000000000909c  /data/app/com.me.linjw.ndkdemo-qgq0-FTl7SRsBBdmCeMAdg==/oat/arm64/base.odex (offset 0x9000) 
    10.

从这里我们可以分析到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. 
  
  
  
  
  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) 
    3.

C++ 编译器的函数名修饰

细心的同学可能会有疑问,函数名明明是显示的_Z9willCrashv,为啥我会说是willCrash?它和下面的Java_com_me_linjw_ndkdemo_MainActivity_callNative有什么区别?

我们可以先来看看源代码确认下我没有骗你:

那为什么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行:

这里我们来解释下+号后面的值的意义。我们都知道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. 
  
  
  
  
  2. ./20.0.5594570/toolchains/x86-4.9/prebuilt/darwin-x86_64/bin/i686-linux-android-objdump 
    3. 
  
  
  
  
  3. ./20.0.5594570/toolchains/x86-4.9/prebuilt/darwin-x86_64/i686-linux-android/bin/objdump 
    4. 
  
  
  
  
  4. ./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/aarch64-linux-android/bin/objdump 
    5. 
  
  
  
  
  5. ./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/bin/x86_64-linux-android-objdump 
    6. 
  
  
  
  
  6. ./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android-objdump 
    7. 
  
  
  
  
  7. ./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/bin/i686-linux-android-objdump 
    8. 
  
  
  
  
  8. ./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-objdump 
    9. 
  
  
  
  
  9. ./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/arm-linux-androideabi/bin/objdump 
    10. 
  
  
  
  
  10. ./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/x86_64-linux-android/bin/objdump 
    11. 
  
  
  
  
  11. ./20.0.5594570/toolchains/llvm/prebuilt/darwin-x86_64/i686-linux-android/bin/objdump 
    12. 
  
  
  
  
  12. ./20.0.5594570/toolchains/x86_64-4.9/prebuilt/darwin-x86_64/bin/x86_64-linux-android-objdump 
    13. 
  
  
  
  
  13. ./20.0.5594570/toolchains/x86_64-4.9/prebuilt/darwin-x86_64/x86_64-linux-android/bin/objdump 
    14. 
  
  
  
  
  14. ./20.0.5594570/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-objdump 
    15. 
  
  
  
  
  15. ./20.0.5594570/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/arm-linux-androideabi/bin/objdump 
    16. 
  
  
  
  
  16. ./20.0.5594570/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/aarch64-linux-android/bin/objdump 
    17. 
  
  
  
  
  17. ./20.0.5594570/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-objdump 
    18.

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

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

然后我们搜索Java_com_me_linjw_ndkdemo_MainActivity_callNative找到这个方法的定义:

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

然后我们上面看到的pc 000000000000f728其实指的就是f728这个地址的指令,也就是bl指令,这个指令用于调用子程序,于是我们可以容易猜出这行指令的作用是跳转到willCrash方法:

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

而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. 
  
  
  
  
  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) 
    3.

使用这个命令的前提是我们要有带符号的so库,因为一般情况下打包到apk里面的so都是不带符号的(可以大概理解成java层的混淆,去掉了符号信息),所以如果直接从apk里面解压出so,然后使用addr2line会得到下面结果，全是问号:

 
 
 
 
    
  
  
  
  
  1. ??:? 
    2.

带符号的so一般会在编译的过程中生成,所以可以在app/build目录里面递归搜索下,而且不同cpu架构也需要用不同的addr2line,命令如下:

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

得到结果:

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

我们来对比下源码就能找到崩溃的原因是delete了字符串常量的内存:

ndk-stack作为认真看到这里的同学,我必须要奖励好学的你一个福利,那就是ndk-stack,他也在ndk里面:

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

首先我们将含有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 
    2.

然后它就会对native堆栈使用addr2line和目录下的so去转换,最终输出带符号的堆栈信息:

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

ndk-stack在开始解析 logcat 输出时将查找第一行星号,所以拷贝的时候记得这行不能缺少:

 
 
 
 
    
  
  
  
  
  1. *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 
    2.

当然通常情况下我们直接将logcat出来的所有日志传给它就好，它会自动根据星号行识别出native堆栈:

 
 
 
 
    
  
  
  
  
  1. adb logcat | ndk-stack路径 -sym 存放带符号so库目录的路径 
    2.

新闻标题：AndroidNDKCrash定位分析
网页网址：http://www.gawzjz.com/qtweb2/news23/4623.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

关键词优化知识

同城分类信息

成都免费做网站公司　　 　青羊区雕琢时光　　 　创新互联重庆　　 　广安网站设计　　 　成都主机租用　　 　成都定制网站建设　　 　江油做网站　　 　成都虚拟主机　　 　门户网站建设方案　　 　眉山联通机房　　 　西云服务器托管　　 　界面设计　　 　手机网站制作　　 　节能环保网站建设方案　　 　四川国泰民安消防　　 　成都微信开发　　 　雅安服务器托管　　 　成都装饰装修　　 　成都云主机　　 　自适应网站建设