苹果手机crash日志怎么用symbolicatecrash分析
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了苹果手机crash日志怎么用symbolicatecrash分析相关的知识,希望对你有一定的参考价值。
参考技术A 首先在进入到mac的指定的文件进行获取到crash的文件,一般的crash的文件在这个路径下,~/Library/Logs/CrashReporter/MobileDevice/,就到找需要的crash的文件。然后找到mac中的电脑中的生成app的路径下中,即是xcode开发完成并编译成功的app的文件都是会在路径下,/Users/luo/Library/Developer/Xcode/DerivedData/TestAutomation-eawlwelvvpqdzsbdqoptakrdprvn/Build/Products/Debug-iphonesimulator/,即是生成app的路径,进行该路径下。把crash的文件复制该目录下。
需要crash的查看uuid的是否一致,进行执行dwarfdump --uuid TestAutomation.app/TestAutomation,生成的结果中就可以查看到uuid的值,方法一致,一一查看crash的文件。
需要找到symbolicatecrash ,进入到该文件下/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/,就可以找到。
然后进行执行symbolicatecrash ***.crash ***.app >testapp.log,
这样就把crash的log文件,转换成可以查看的文件内容信息。根据这个log日志信息,进行分析日志信息。
Android Native crash日志分析
在Android应用crash的类型中,native类型crash应该是比较难的一种了,因为大家接触的少,然后相对也要多转几道工序,所有大部分对这个都比较生疏。虽然相关文章也有很多了,但是我在刚开始学的过程中还是遇到一些问题,下面一一记录,以便将来翻阅。
分析native crash 日志需要几个东西:
- addr2line,objdump,ndk-stack等几个工具
- 带symbols的so文件
- log
log
native crash的日志都是从一行星号(*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***)开始,这行星号也是ndk-stack工具用来查找native crash的标志。一个native crash日志例子:
1 04-16 11:18:00.323 26512 26512 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 2 04-16 11:18:00.324 26512 26512 F DEBUG : Build fingerprint: ‘nubia/NX531J/NX531J:7.1.1/NMF26F/nubia04130311:user/release-keys‘ 3 04-16 11:18:00.324 26512 26512 F DEBUG : Revision: ‘0‘ 4 04-16 11:18:00.324 26512 26512 F DEBUG : ABI: ‘arm‘ 5 04-16 11:18:00.324 26512 26512 F DEBUG : pid: 26452, tid: 26491, name: Thread-4 >>> com.willhua.opencvstudy <<< 6 04-16 11:18:00.324 26512 26512 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xc8080000 7 04-16 11:18:00.324 26512 26512 F DEBUG : r0 c807a400 r1 c7e80000 r2 00000069 r3 00000069 8 04-16 11:18:00.324 26512 26512 F DEBUG : r4 caa4ca9c r5 007e9000 r6 00000964 r7 c69838f8 9 04-16 11:18:00.324 26512 26512 F DEBUG : r8 00005c00 r9 00017002 sl 001fa400 fp cac6ec00 10 04-16 11:18:00.324 26512 26512 F DEBUG : ip e71aac64 sp c69838e8 lr caa8e949 pc caa8e97c cpsr 800f0030 11 04-16 11:18:00.326 26512 26512 F DEBUG : 12 04-16 11:18:00.326 26512 26512 F DEBUG : backtrace: 13 04-16 11:18:00.326 26512 26512 F DEBUG : #00 pc 0004097c /data/app/com.willhua.opencvstudy-1/lib/arm/libOpenCV.so (_Z14darkGrayThreadPv+179) 14 04-16 11:18:00.326 26512 26512 F DEBUG : #01 pc 000475d3 /system/lib/libc.so (_ZL15__pthread_startPv+22) 15 04-16 11:18:00.326 26512 26512 F DEBUG : #02 pc 00019d3d /system/lib/libc.so (__start_thread+6)
带symbols的so文件
对于比如手机公司的开发人员来说,一般来说出问题的so对应的带symbols的so都在out/target/product/<model_name>/symbols/system/lib/下面,而对于常见的使用AndroidStudio开发的单个应用来说,其对应的带symbols的在<PROJECT_ROOT>\app\src\main\obj\local\<ABI>\下面的so,而不能是\app\src\main\libs\<ABI>的,这里面的是不包含symbols信息的,拿这个去分析,输出的结果就是“??:?”。其实这两个so的体积对比也是很明显的的,在我的应用中,前一个带symbols的so的体积为7M多,而后一个只有2M。
分析工具
- addr2line:用来分析单个pc地址对应的源码行数,比如示例log中的第13行中的#00 pc 0004097c,0004097c就是crash时pc调用的堆栈地址,用这个地址就可以分析出对应在源码中的行数;
- objdump:用来把相应的so变成汇编语言的asm文件,然后根据地址信息(比如0004097c)就可以找到更加详细的相关函数信息;
- ndk-stack:用来把log信息全部翻译成更加详细的带源码行数信息的log,相当于是在整个crash堆栈信息都执行addr2line命令。
对于使用linux系统作为开发环境的,linux就自带addr2line命令。而对于笔者这种使用Windows的,在sdk中安装了NDK之后,在ndk中就带有这些工具。
比如addr2line工具在:sdk\ndk-bundle\toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin下面,同时这个bin下面包含很多其他工具,比如objdump,readelf等;
ndk-stack工具则在sdk\ndk-bundle下面;
关于这些工具的具体使用,在https://www.oschina.net/question/2241352_213433这篇文章中讲的很详细,我也就不再重复。
但是提醒一点:crash log与对应的so一定要对应起来。即错误的情况是:你拿了一份旧的log,然后你修改了so相关的源码,然后编译出来了新的so,你拿着这个新的so以及旧log中的地址去让addr2line等分析,那肯定是是得不到正确的结果的。
刚刚提到的那篇文章讲的很详细,为了避免以后找不到所以我就把它复制到这里。
/****************************************************************************************************************************************/
转自:https://www.oschina.net/question/2241352_213433
Android NDK是什么,为什么我们要用NDK?
Android NDK 是在SDK前面又加上了“原生”二字,即Native Development Kit,因此又被Google称为“NDK”。众所周知,Android程序运行在Dalvik虚拟机中,NDK允许用户使用类似C / C++之类的原生代码语言执行部分程序。NDK包括了:
- 从C / C++生成原生代码库所需要的工具和build files。
- 将一致的原生库嵌入可以在Android设备上部署的应用程序包文件(application packages files,即.apk文件)中。
- 支持所有未来Android平台的一些列原生系统头文件和库
为何要用到NDK?概括来说主要分为以下几种情况:
- 代码的保护,由于apk的java层代码很容易被反编译,而C/C++库反汇难度较大。
- 在NDK中调用第三方C/C++库,因为大部分的开源库都是用C/C++代码编写的。
- 便于移植,用C/C++写的库可以方便在其他的嵌入式平台上再次使用。
Android JNI是什么?和NDK是什么关系?
Java Native Interface(JNI)标准是java平台的一部分,它允许Java代码和其他语言写的代码进行交互。JNI是本地编程接口,它使得在 Java 虚拟机(VM) 内部运行的 Java 代码能够与用其它编程语言(如 C、C++和汇编语言)编写的应用程序和库进行交互操作。
简单来说,可以认为NDK就是能够方便快捷开发.so文件的工具。JNI的过程比较复杂,生成.so需要大量操作,而NDK就是简化了这个过程。
NDK的异常会不会导致程序Crash,NDK的常见的有哪些类型异常?
NDK编译生成的.so文件作为程序的一部分,在运行发生异常时同样会造成程序崩溃。不同于Java代码异常造成的程序崩溃,在NDK的异常发生时,程序在Android设备上都会立即退出,即通常所说的闪退,而不会弹出“程序xxx无响应,是否立即关闭”之类的提示框。
NDK是使用C/C++来进行开发的,熟悉C/C++的程序员都知道,指针和内存管理是最重要也是最容易出问题的地方,稍有不慎就会遇到诸如内存无效访问、无效对象、内存泄露、堆栈溢出等常见的问题,最后都是同一个结果:程序崩溃。例如我们常说的空指针错误,就是当一个内存指针被置为空(NULL)之后再次对其进行访问;另外一个经常出现的错误是,在程序的某个位置释放了某个内存空间,而后在程序的其他位置试图访问该内存地址,这就会产生一个无效地址错误。常见的错误类型如下:
- 初始化错误
- 访问错误
- 数组索引访问越界
- 指针对象访问越界
- 访问空指针对象
- 访问无效指针对象
- 迭代器访问越界
- 内存泄露
- 参数错误
- 堆栈溢出
- 类型转换错误
- 数字除0错误
NDK错误发生时,我们能拿到什么信息?
利用Android NDK开发本地应用的时候,几乎所有的程序员都遇到过程序崩溃的问题,但它的崩溃会在logcat中打印一堆看起来类似天书的堆栈信息,让人举足无措。单靠添加一行行的打印信息来定位错误代码做在的行数,无疑是一件令人崩溃的事情。在网上搜索“Android NDK崩溃”,可以搜索到很多文章来介绍如何通过Android提供的工具来查找和定位NDK的错误,但大都晦涩难懂。下面以一个实际的例子来说明,首先生成一个错误,然后演示如何通过两种不同的方法,来定位错误的函数名和代码行。
首先,看我们在hello-jni程序的代码中做了什么(有关如何创建或导入工程,此处略),看下图:在JNI_OnLoad()的函数中,即so加载时,调用willCrash()函数,而在willCrash()函数中, std::string的这种赋值方法会产生一个空指针错误。这样,在hello-jni程序加载时就会闪退。我们记一下这两个行数:在61行调用了willCrash()函数;在69行发生了崩溃。
下面来看看发生崩溃(闪退)时系统打印的logcat日志:
- *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
- Build fingerprint: ‘vivo/bbk89_cmcc_jb2/bbk89_cmcc_jb2:4.2.1/JOP40D/1372668680:user/test-keys‘
- pid: 32607, tid: 32607, name: xample.hellojni >>> com.example.hellojni <<<
- signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
- r0 00000000 r1 beb123a8 r2 80808080 r3 00000000
- r4 5d635f68 r5 5cdc3198 r6 41efcb18 r7 5d62df44
- r8 4121b0c0 r9 00000001 sl 00000000 fp beb1238c
- ip 5d635f7c sp beb12380 lr 5d62ddec pc 400e7438 cpsr 60000010
- backtrace:
- #00 pc 00023438 /system/lib/libc.so
- #01 pc 00004de8 /data/app-lib/com.example.hellojni-2/libhello-jni.so
- #02 pc 000056c8 /data/app-lib/com.example.hellojni-2/libhello-jni.so
- #03 pc 00004fb4 /data/app-lib/com.example.hellojni-2/libhello-jni.so
- #04 pc 00004f58 /data/app-lib/com.example.hellojni-2/libhello-jni.so
- #05 pc 000505b9 /system/lib/libdvm.so
- #06 pc 00068005 /system/lib/libdvm.so
- #07 pc 000278a0 /system/lib/libdvm.so
- #08 pc 0002b7fc /system/lib/libdvm.so
- #09 pc 00060fe1 /system/lib/libdvm.so
- #10 pc 0006100b /system/lib/libdvm.so
- #11 pc 0006c6eb /system/lib/libdvm.so
- #12 pc 00067a1f /system/lib/libdvm.so
- #13 pc 000278a0 /system/lib/libdvm.so
- #14 pc 0002b7fc /system/lib/libdvm.so
- #15 pc 00061307 /system/lib/libdvm.so
- #16 pc 0006912d /system/lib/libdvm.so
- #17 pc 000278a0 /system/lib/libdvm.so
- #18 pc 0002b7fc /system/lib/libdvm.so
- #19 pc 00060fe1 /system/lib/libdvm.so
- #20 pc 00049ff9 /system/lib/libdvm.so
- #21 pc 0004d419 /system/lib/libandroid_runtime.so
- #22 pc 0004e1bd /system/lib/libandroid_runtime.so
- #23 pc 00001d37 /system/bin/app_process
- #24 pc 0001bd98 /system/lib/libc.so
- #25 pc 00001904 /system/bin/app_process
- stack:
- beb12340 012153f8
- beb12344 00054290
- beb12348 00000035
- beb1234c beb123c0 [stack]
- ……
如果你看过logcat打印的NDK错误时的日志就会知道,我省略了后面很多的内容,很多人看到这么多密密麻麻的日志就已经头晕脑胀了,即使是很多资深的Android开发者,在面对NDK日志时也大都默默的选择了无视。
“符号化”NDK错误信息的方法
其实,只要你细心的查看,再配合Google 提供的工具,完全可以快速的准确定位出错的代码位置,这个工作我们称之为“符号化”。需要注意的是,如果要对NDK错误进行符号化的工作,需要保留编译过程中产生的包含符号表的so文件,这些文件一般保存在$PROJECT_PATH/obj/local/目录下。
第一种方法:ndk-stack
这个命令行工具包含在NDK工具的安装目录,和ndk-build和其他一些常用的NDK命令放在一起,比如在我的电脑上,其位置是/android-ndk-r9d/ndk-stack。根据Google官方文档,NDK从r6版本开始提供ndk-stack命令,如果你用的之前的版本,建议还是尽快升级至最新的版本。使用ndk –stack命令也有两种方式
使用ndk-stack实时分析日志
在运行程序的同时,使用adb获取logcat日志,并通过管道符输出给ndk-stack,同时需要指定包含符号表的so文件位置;如果你的程序包含了多种CPU架构,在这里需求根据错误发生时的手机CPU类型,选择不同的CPU架构目录,如:
- adb shell logcat | ndk-stack -sym $PROJECT_PATH/obj/local/armeabi
当崩溃发生时,会得到如下的信息:
- ********** Crash dump: **********
- Build fingerprint: ‘vivo/bbk89_cmcc_jb2/bbk89_cmcc_jb2:4.2.1/JOP40D/1372668680:user/test-keys‘
- pid: 32607, tid: 32607, name: xample.hellojni >>> com.example.hellojni <<<
- signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
- Stack frame #00 pc 00023438 /system/lib/libc.so (strlen+72)
- Stack frame #01 pc 00004de8 /data/app-lib/com.example.hellojni-2/libhello-jni.so (std::char_traits<char>::length(char const*)+20): Routine std::char_traits<char>::length(char const*) at /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/char_traits.h:229
- Stack frame #02 pc 000056c8 /data/app-lib/com.example.hellojni-2/libhello-jni.so (std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)+44): Routine basic_string at /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/_string.c:639
- Stack frame #03 pc 00004fb4 /data/app-lib/com.example.hellojni-2/libhello-jni.so (willCrash()+68): Routine willCrash() at /home/testin/hello-jni/jni/hello-jni.cpp:69
- Stack frame #04 pc 00004f58 /data/app-lib/com.example.hellojni-2/libhello-jni.so (JNI_OnLoad+20): Routine JNI_OnLoad at /home/testin/hello-jni/jni/hello-jni.cpp:61
- Stack frame #05 pc 000505b9 /system/lib/libdvm.so (dvmLoadNativeCode(char const*, Object*, char**)+516)
- Stack frame #06 pc 00068005 /system/lib/libdvm.so
- Stack frame #07 pc 000278a0 /system/lib/libdvm.so
- Stack frame #08 pc 0002b7fc /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+180)
- Stack frame #09 pc 00060fe1 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+272)
- ……(后面略)
我们重点看一下#03和#04,这两行都是在我们自己生成的libhello-jni.so中的报错信息,那么会发现如下关键信息:
- #03 (willCrash()+68): Routine willCrash() at /home/testin/hello-jni/jni/hello-jni.cpp:69
- #04 (JNI_OnLoad+20): Routine JNI_OnLoad at /home/testin/hello-jni/jni/hello-jni.cpp:61
回想一下我们的代码,在JNI_OnLoad()函数中(第61行),我们调用了willCrash()函数;在willCrash()函数中(第69行),我们制造了一个错误。这些信息都被准确无误的提取了出来!是不是非常简单?
先获取日志,再使用ndk-stack分析
这种方法其实和上面的方法没有什么大的区别,仅仅是logcat日志获取的方式不同。可以在程序运行的过程中将logcat日志保存到一个文件,甚至可以在崩溃发生时,快速的将logcat日志保存起来,然后再进行分析,比上面的方法稍微灵活一点,而且日志可以留待以后继续分析。
- adb shell logcat > 1.log
- ndk-stack -sym $PROJECT_PATH/obj/local/armeabi –dump 1.log
第二种方法:使用addr2line和objdump命令
这个方法适用于那些,不满足于上述ndk-stack的简单用法,而喜欢刨根问底的程序员们,这两个方法可以揭示ndk-stack命令的工作原理是什么,尽管用起来稍微麻烦一点,但是可以满足一下程序员的好奇心。
先简单说一下这两个命令,在绝大部分的linux发行版本中都能找到他们,如果你的操作系统是linux,而你测试手机使用的是Intel x86系列,那么你使用系统中自带的命令就可以了。然而,如果仅仅是这样,那么绝大多数人要绝望了,因为恰恰大部分开发者使用的是Windows,而手机很有可能是armeabi系列。
别急,在NDK中自带了适用于各个操作系统和CPU架构的工具链,其中就包含了这两个命令,只不过名字稍有变化,你可以在NDK目录的toolchains目录下找到他们。以我的Mac电脑为例,如果我要找的是适用于armeabi架构的工具,那么他们分别为arm-linux-androideabi-addr2line和arm-linux-androideabi-objdump;位置在下面目录中,后续介绍中将省略此位置:
- /Developer/android_sdk/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/
假设你的电脑是windows, CPU架构为mips,那么你要的工具可能包含在这个目录中:
- D:\ android-ndk-r9d\toolchains\mipsel-linux-android-4.8\prebuilt\windows-x86_64\bin\
好了言归正传,如何使用这两个工具,下面具体介绍:
1. 找到日志中的关键函数指针
其实很简单,就是找到backtrace信息中,属于我们自己的so文件报错的行。
首先要找到backtrace信息,有的手机会明确打印一行backtrace(比如我们这次使用的手机),那么这一行下面的一系列以“#两位数字 pc”开头的行就是backtrace信息了。有时可能有的手机并不会打印一行backtrace,那么只要找到一段以“#两位数字 pc ”开头的行,就可以了。
其次要找到属于自己的so文件报错的行,这就比较简单了。找到这些行之后,记下这些行中的函数地址
2. 使用addr2line查找代码位置
执行如下的命令,多个指针地址可以在一个命令中带入,以空格隔开即可
- arm-linux-androideabi-addr2line –e obj/local/armeabi/libhello-jni.so 00004de8 000056c8 00004fb4 00004f58
结果如下
- /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/char_traits.h:229
- /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/_string.c:639
- /WordSpaces/hello-jni/jni/hello-jni.cpp:69
- /WordSpaces hello-jni/jni/hello-jni.cpp:6
从addr2line的结果就能看到,我们拿到了我们自己的错误代码的调用关系和行数,在hello-jni.cpp的69行和61行(另外两行因为使用的是标准函数,可以忽略掉),结果和ndk-stack是一致的,说明ndk-stack也是通过addr2line来获取代码位置的。
3. 使用objdump获取函数信息
通过addr2line命令,其实我们已经找到了我们代码中出错的位置,已经可以帮助程序员定位问题所在了。但是,这个方法只能获取代码行数,并没有显示函数信息,显得不那么“完美”,对于追求极致的程序员来说,这当然是不够的。下面我们就演示怎么来定位函数信息。
使用如下命令导出函数表:
- arm-linux-androideabi-objdump –S obj/local/armeabi/libhello-jni.so > hello.asm
在生成的asm文件中查找刚刚我们定位的两个关键指针00004fb4和00004f58
从这两张图可以清楚的看到(要注意的是,在不同的NDK版本和不同的操作系统中,asm文件的格式不是完全相同,但都大同小异,请大家仔细比对),这两个指针分别属于willCrash()和JNI_OnLoad()函数,再结合刚才addr2line的结果,那么这两个地址分别对应的信息就是:
- 00004fb4: willCrash() /WordSpaces/hello-jni/jni/hello-jni.cpp:69
- 00004f58: JNI_OnLoad()/WordSpaces/hello-jni/jni/hello-jni.cpp:61
相当完美,和ndk-stack得到的信息完全一致!
使用Testin崩溃分析服务定位NDK错误
以上提到的方法,只适合在开发测试期间,如果你的应用或者游戏已经发布上线,而用户经常反馈说崩溃、闪退,指望用户帮你收集信息定位问题,几乎是不可能的。这个时候,我们就需要用其他的手段来捕获崩溃信息。
目前业界已经有一些公司推出了崩溃信息收集的服务,通过嵌入SDK,在程序发生崩溃时收集堆栈信息,发送到云服务平台,从而帮助开发者定位错误信息。在这方面,处于领先地位的是国内的Testin和国外的crittercism,其中crittercism需要付费,而且没有专门的中国开发者支持,我们更推荐Testin,其崩溃分析服务是完全免费的。
Testin从1.4版本开始支持NDK的崩溃分析,其最新版本已经升级到1.7。当程序发生NDK错误时,其内嵌的SDK会收集程序在用户手机上发生崩溃时的堆栈信息(主要就是上面我们通过logcat日志获取到的函数指针)、设备信息、线程信息等等,SDK将这些信息上报至Testin云服务平台,只要登陆到Testin平台,就可以看到所有用户上报的崩溃信息,包括NDK;并且这些崩溃做过归一化的处理,在不同系统和ROM的版本上打印的信息会略有不同,但是在Testin的网站上这些都做了很好的处理,避免了我们一些重复劳动。
上图的红框部分,就是从用户手机上报的,我们自己的so中报错的函数指针地址堆栈信息,就和我们开发时从logcat读到的日志一样,是一些晦涩难懂的指针地址,Testin为NDK崩溃提供了符号化的功能,只要将我们编译过程中产生的包含符号表的so文件上传(上文我们提到过的obj/local/目录下的适用于各个CPU架构的so),就可以自动将函数指针地址定位到函数名称和代码行数。符号化之后,看起来就和我们前面在本地测试的结果是一样的了,一目了然。
而且使用这个功能还有一个好处:这些包含符号表的so文件,在每次我们自己编译之后都会改变,很有可能我们刚刚发布一个新版本,这些目录下的so就已经变了,因为开发者会程序的修改程序;在这样的情况下,即使我们拿到了崩溃时的堆栈信息,那也无法再进行符号化了。所以我们在编译打包完成后记得备份我们的so文件。这时我们可以将这些文件上传到Testin进行符号化的工作,Testin会为我们保存和管理不同版本的so文件,确保信息不会丢失。来看一下符号化之后的显示:
以上是关于苹果手机crash日志怎么用symbolicatecrash分析的主要内容,如果未能解决你的问题,请参考以下文章