iOS崩溃统计原理 & 日志分析整理

简介

当应用崩溃时,会产生崩溃日志并且保存在设备上。崩溃日志描述了应用结束时所处的环境信息,通常包含完整的线程堆栈追溯信息,这些数据对于调试应用错误非常有帮助。
包含追溯信息的崩溃日志在分析前需要进行符号化。符号化将内存地址替换为更直观的函数名以及行数。

崩溃原因

崩溃是指应用产生了系统不允许的行为时,系统终止其运行导致的现象。崩溃发生的原因有:

1、存在CPU无法运行的代码
不存在或者无法执行
2、操作系统执行某项策略,终止程序
启动时间过长或者消耗过多内存时,操作系统会终止程序运行
3、编程语言为了避免错误终止程序:抛出异常
4、开发者为了避免失败终止程序:Assert

产生崩溃日志

在程序出现以上问题时,系统会抛出异常,结束程序:
出现异常情况,终止程序:


分析崩溃日志

在发生崩溃时,会产生崩溃日志并且保存在设备上,用于后期对问题定位,崩溃日志的内容包括以下部分:程序信息、异常信息、崩溃堆栈、二进制镜像。下面对每部分进行说明。

崩溃日志程序信息:

Incident Identifier: B6FD1E8E-B39F-430B-ADDE-FC3A45ED368C
CrashReporter Key: f04e68ec62d3c66057628c9ba9839e30d55937dc
Hardware Model: iPad6,8
Process: TheElements [303]
Path: /private/var/containers/Bundle/Application/888C1FA2-3666-4AE2-9E8E-62E2F787DEC1/TheElements.app/TheElements
Identifier: com.example.apple-samplecode.TheElements
Version: 1.12
Code Type: ARM-64 (Native)
Role: Foreground
Parent Process: launchd [1]
Coalition: com.example.apple-samplecode.TheElements [402]

Date/Time: 2016-08-22 10:43:07.5806 -0700
Launch Time: 2016-08-22 10:43:01.0293 -0700
OS Version: iPhone OS 10.0 (14A5345a)
Report Version: 104

汇总部分包含崩溃发生环境的基本信息:

1、Incident Identifier:日志ID。

2、CrashReport Key:设备匿名ID,同一设备的崩溃日志该值相同。

3、Beta Identifier:设备和崩溃应用组合ID。

4、Process:执行程序名,等同CFBundleExecutable。

5、Version:程序版本号,等同CFBundleVersion/CFBundleVersionString。

6、Code type:程序构造:ARM-64、ARM、x86

异常信息:

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]
Triggered by Thread: 0

异常信息:

1、Exception Codes:使用十六进制表示的程序特定信息,一般不展示。

2、Exception Subtype:易读(相比十六进制地址)的异常信息。

3、Exception Message:异常的额外信息。

4、Exception Note:不特指某种异常类型的额外信息。

5、Termination Reason:程序终止的异常信息。

6、Triggered Thread:异常发生时的线程。

崩溃堆栈:

Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 TheElements 0x000000010006bc20 -[AtomicElementViewController myTransitionDidStop:finished:context:] (AtomicElementViewController.m:203)
1 UIKit 0x0000000194cef0f0 -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 312
2 UIKit 0x0000000194ceef30 -[UIViewAnimationState animationDidStop:finished:] + 160
3 QuartzCore 0x0000000192178404 CA::Layer::run_animation_callbacks(void*) + 260
4 libdispatch.dylib 0x000000018dd6d1c0 _dispatch_client_callout + 16
5 libdispatch.dylib 0x000000018dd71d6c _dispatch_main_queue_callback_4CF + 1000
6 CoreFoundation 0x000000018ee91f2c __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
7 CoreFoundation 0x000000018ee8fb18 __CFRunLoopRun + 1660
8 CoreFoundation 0x000000018edbe048 CFRunLoopRunSpecific + 444
9 GraphicsServices 0x000000019083f198 GSEventRunModal + 180
10 UIKit 0x0000000194d21bd0 -[UIApplication _run] + 684
11 UIKit 0x0000000194d1c908 UIApplicationMain + 208
12 TheElements 0x00000001000653c0 main (main.m:55)
13 libdyld.dylib 0x000000018dda05b8 start + 4

Thread 1:
0 libsystem_kernel.dylib 0x000000018deb2a88 __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x000000018df75188 _pthread_wqthread + 968
2 libsystem_pthread.dylib 0x000000018df74db4 start_wqthread + 4

...

第一行列出了线程信息以及所在队列,之后是追溯链中独立栈帧的详细信息:

1、栈帧号。栈帧号为0的代表当前执行停顿的函数,1则是调用当前停顿函数的主调函数,即0为1的被调函数,1为0的主调函数,以此类推。
2、执行函数所在的二进制包
3、地址信息:对于0栈帧来说,代表当前执行停顿的地址。其他栈帧则是获取控制权后接下来执行的地址。
4、函数名

二进制镜像:

Binary Images:
0x100060000 - 0x100073fff TheElements arm64 <2defdbea0c873a52afa458cf14cd169e> /var/containers/Bundle/Application/888C1FA2-3666-4AE2-9E8E-62E2F787DEC1/TheElements.app/TheElements
...

日之内包含多个二进制镜像,每个二进制镜像内包含以下信息:

1、二进制镜像在程序内的地址空间
2、二进制的名称或者bundleID
3、二进制镜像的架构信息 arm64等
4、二进制镜像的UUID,每次构建都会改变,该值用于在符号化日志时定位对应的dSYM文件。
5、磁盘上的二进制路径

符号化

app.xcarchive文件,包内容包含dSYM和应用的二进制文件。
更精确的符号化,可以结合崩溃日志、项目二进制文件、dSYM文件,对其进行反汇编,从而获得更详细的信息。

符号化就是将追溯的地址信息转换成函数名及行数等信息,便于研发人员定位问题。
当程序结束运行时,会产生崩溃日志,日志内包含每个线程的堆栈信息。当我们使用Xcode进行调试时,崩溃或者断点信息都会展示出实例和方法名等信息(符号信息)。相反,当应用被发布后,符号信息并不会包含在应用的二进制文件中,所以服务端收到的是未符号化的包含十六进制地址信息的日志文件。
查看本机崩溃日志步骤如下:

1、将手机连接到Mac
2、启动Xcode->Window->Devices and simulators
3、选择View Device Logs

选择左侧应用,之后就可以在右侧看到崩溃日志信息:


日志内包含符号化内容-[__NSArrayI objectAtIndex:]和十六进制地址0x000db142 0xb1000 + 172354。这种日志类型成为部分符号化崩溃日志。
部分符号化的原因在于,Xcode只能符号化系统组件,例如UIKit、CoreFoundation等。但是对于非系统库产生的崩溃,在没有符号表的情况下就无法符号化。
分析第三行未符号化的代码:

0x000db142 0xb1000 + 172354

以上内容说明了崩溃发生在内存地址0x000db142,此地址和0xb1000 + 172354是相等的。0xb1000代表这部分许的起始地址,172354代表偏移位。

崩溃日志类型:

崩溃日志可能包含几种状态:未符号化、完全符号化、部分符号化。
未符号化的崩溃日志追溯链中没有函数的名字等信息,而是二进制镜像执行代码的十六进制地址。
完全符号化的崩溃日志中,所有的十六进制地址都被替换为对应的函数符号。

符号化流程

符号化需要两部分内容:崩溃的二进制代码和编译产生的对应dSYM。

符号表

当编译器将源码转换为机器码时,会生成一个调试符号表,表内是二进制结构到原始源码的映射关系。调试符号表保存在dSYM(debug symbol调试符号表)文件内。调试模式下符号表会保存在编译的二进制内,发布模式则将符号表保存在dSYM文件内用于减少包的体积。

当崩溃发生时,会在设备存储一份未符号化的崩溃日志
获取崩溃日志后,通过dSYM对追溯链中的每个地址进行符号化,转换为函数信息,产生的结果就是符号化后的崩溃日志。

函数调用堆栈

我们知道,崩溃日志内包含函数调用的追溯信息,明白堆栈是怎么产生的有利于我们理解和分析崩溃日志。


函数调用是在栈进行的,函数从调用和被调用方分为:主调函数和被调函数,这次我们只讨论每个函数在栈中的几个核心部分:

1、上一个函数(主调函数)的堆栈信息。
2、入参。
3、局部变量。

入参和局部变量容易理解,下面讨论为什么要保存主调函数的堆栈信息。
说到这点就需要聊到寄存器。

寄存器


寄存器的类型和基本功能:

eax:累加寄存器,用于运算。
ebx:基址寄存器,用于地址索引。
ecx:计数寄存器,用于计数。
edx:数据寄存器,用于数据传递。
esi:源变址寄存器,存放相对于DS段之源变址指针。
edi:目的变址寄存器,存放相对于ES段之目的的变址指针。
esp:堆栈指针,指向当前堆栈位置。
ebp:基址指针寄存器,相对基址位置。

寄存器约定

背景:

1、所有函数都可以访问和操作寄存器,寄存器对于单个CPU来说数量是固定的
2、单个CPU来说,某一时刻只有一个函数在执行
3、需要保证函数调用其他函数时,被调函数不会修改或覆盖主调函数稍后使用的寄存器值

被调函数在执行时,需要使用寄存器来保存数据和执行计算,但是在被调函数完成时,需要把寄存器还原,用于主调函数的执行,所以出现了寄存器约定。

约定内容:

1、主调函数的保存寄存器,在唤起被调函数前,需要显示的将其保存在栈中。
主调寄存器:%eax、%edx、%ecx
2、被调函数的保存寄存器,使用前压栈,并在函数返回前从栈中恢复原值。
被调寄存器:%ebx、%esi、%edi
3、被调函数必须保存%ebp和%esp,并在函数返回后恢复调用前的值。

遵守寄存器约定的函数堆栈调用

了解了寄存器功能和寄存器约定后,我们再看函数调用堆栈:


1、栈帧逻辑:栈帧的边界由栈帧基地址指针EBP和堆栈指针ESP界定(指针存放在相应寄存器中)。EBP指向当前栈帧底部(高地址),在当前栈帧内位置固定;ESP指向当前栈帧顶部(低地址),当程序执行时ESP会随着数据的入栈和出栈而移动。因此函数中对大部分数据的访问都基于EBP进行。
2、保存栈帧:被调函数必须保持寄存器%ebp和%esp,并在函数返回后将其恢复到调用前的值,亦即必须恢复主调函数的栈帧。
3、回溯:所以获取到崩溃时线程的ebp和esp 就能回溯到上一个调用,依次类推,回溯出所有的调用堆栈

总结

通过以上内容,我们了解了崩溃日志产生原理、崩溃日志内容和崩溃日志分析,下面分享几个分析崩溃日志的小提示作为结束:

1、不止关注崩溃本行,结合上下文进行分析。
2、不止关注崩溃线程,要结合其他线程的堆栈信息。
3、通过多个崩溃日志,组合分析。
4、使用地址定位和野指针工具重现内存问题。

参考资料

Apple Understanding and Analyzing Application Crash Reports
Overview Of iOS Crash Reporting Tools
Understanding Crashes and Crash Logs Video

链接:https://www.jianshu.com/p/e05498960209

0 个评论

要回复文章请先登录注册