简介
当应用崩溃时，会产生崩溃日志并且保存在设备上。崩溃日志描述了应用结束时所处的环境信息，通常包含完整的线程堆栈追溯信息，这些数据对于调试应用错误非常有帮助。
包含追溯信息的崩溃日志在分析前需要进行符号化。符号化将内存地址替换为更直观的函数名以及行数。
崩溃原因
崩溃是指应用产生了系统不允许的行为时，系统终止其运行导致的现象。崩溃发生的原因有：
- 存在CPU无法运行的代码
不存在或者无法执行 - 操作系统执行某项策略，终止程序
启动时间过长或者消耗过多内存时，操作系统会终止程序运行 - 编程语言为了避免错误终止程序：抛出异常
- 开发者为了避免失败终止程序：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
汇总部分包含崩溃发生环境的基本信息：
Incident Identifier：日志ID。
CrashReport Key：设备匿名ID，同一设备的崩溃日志该值相同。
Beta Identifier：设备和崩溃应用组合ID。
Process：执行程序名，等同CFBundleExecutable。
Version：程序版本号，等同CFBundleVersion/CFBundleVersionString。
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
异常信息：
Exception Codes：使用十六进制表示的程序特定信息，一般不展示。
Exception Subtype：易读（相比十六进制地址）的异常信息。
Exception Message：异常的额外信息。
Exception Note：不特指某种异常类型的额外信息。
Termination Reason：程序终止的异常信息。
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
...
第一行列出了线程信息以及所在队列，之后是追溯链中独立栈帧的详细信息：
- 栈帧号。栈帧号为0的代表当前执行停顿的函数，1则是调用当前停顿函数的主调函数，即0为1的被调函数，1为0的主调函数，以此类推。
- 执行函数所在的二进制包
- 地址信息：对于0栈帧来说，代表当前执行停顿的地址。其他栈帧则是获取控制权后接下来执行的地址。
- 函数名
二进制镜像：
Binary Images:
0x100060000 - 0x100073fff TheElements arm64 <2defdbea0c873a52afa458cf14cd169e> /var/containers/Bundle/Application/888C1FA2-3666-4AE2-9E8E-62E2F787DEC1/TheElements.app/TheElements
...
日之内包含多个二进制镜像，每个二进制镜像内包含以下信息：
- 二进制镜像在程序内的地址空间
- 二进制的名称或者bundleID
- 二进制镜像的架构信息 arm64等
- 二进制镜像的UUID，每次构建都会改变，该值用于在符号化日志时定位对应的dSYM文件。
- 磁盘上的二进制路径
符号化
app.xcarchive文件，包内容包含dSYM和应用的二进制文件。
更精确的符号化，可以结合崩溃日志、项目二进制文件、dSYM文件，对其进行反汇编，从而获得更详细的信息。
符号化就是将追溯的地址信息转换成函数名及行数等信息，便于研发人员定位问题。
当程序结束运行时，会产生崩溃日志，日志内包含每个线程的堆栈信息。当我们使用Xcode进行调试时，崩溃或者断点信息都会展示出实例和方法名等信息（符号信息）。相反，当应用被发布后，符号信息并不会包含在应用的二进制文件中，所以服务端收到的是未符号化的包含十六进制地址信息的日志文件。
查看本机崩溃日志步骤如下：
- 将手机连接到Mac
- 启动Xcode->Window->Devices and simulators
- 选择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对追溯链中的每个地址进行符号化，转换为函数信息，产生的结果就是符号化后的崩溃日志。
函数调用堆栈
我们知道，崩溃日志内包含函数调用的追溯信息，明白堆栈是怎么产生的有利于我们理解和分析崩溃日志。
函数调用是在栈进行的，函数从调用和被调用方分为：主调函数和被调函数，这次我们只讨论每个函数在栈中的几个核心部分：
- 上一个函数（主调函数）的堆栈信息。
- 入参。
- 局部变量。
入参和局部变量容易理解，下面讨论为什么要保存主调函数的堆栈信息。
说到这点就需要聊到寄存器。
寄存器
寄存器的类型和基本功能：
- eax：累加寄存器，用于运算。
- ebx：基址寄存器，用于地址索引。
- ecx：计数寄存器，用于计数。
- edx：数据寄存器，用于数据传递。
- esi：源变址寄存器，存放相对于DS段之源变址指针。
- edi：目的变址寄存器，存放相对于ES段之目的的变址指针。
- esp：堆栈指针，指向当前堆栈位置。
- ebp：基址指针寄存器，相对基址位置。
寄存器约定
背景：
- 所有函数都可以访问和操作寄存器，寄存器对于单个CPU来说数量是固定的
- 单个CPU来说，某一时刻只有一个函数在执行
- 需要保证函数调用其他函数时，被调函数不会修改或覆盖主调函数稍后使用的寄存器值
被调函数在执行时，需要使用寄存器来保存数据和执行计算，但是在被调函数完成时，需要把寄存器还原，用于主调函数的执行，所以出现了寄存器约定。
约定内容：
- 主调函数的保存寄存器，在唤起被调函数前，需要显示的将其保存在栈中。
主调寄存器：%eax、%edx、%ecx - 被调函数的保存寄存器，使用前压栈，并在函数返回前从栈中恢复原值。
被调寄存器：%ebx、%esi、%edi - 被调函数必须保存%ebp和%esp，并在函数返回后恢复调用前的值。
遵守寄存器约定的函数堆栈调用
了解了寄存器功能和寄存器约定后，我们再看函数调用堆栈：
- 栈帧逻辑：栈帧的边界由栈帧基地址指针EBP和堆栈指针ESP界定(指针存放在相应寄存器中)。EBP指向当前栈帧底部(高地址)，在当前栈帧内位置固定；ESP指向当前栈帧顶部(低地址)，当程序执行时ESP会随着数据的入栈和出栈而移动。因此函数中对大部分数据的访问都基于EBP进行。
- 保存栈帧：被调函数必须保持寄存器%ebp和%esp，并在函数返回后将其恢复到调用前的值，亦即必须恢复主调函数的栈帧。
- 回溯：所以获取到崩溃时线程的ebp和esp 就能回溯到上一个调用，依次类推，回溯出所有的调用堆栈
总结
通过以上内容，我们了解了崩溃日志产生原理、崩溃日志内容和崩溃日志分析，下面分享几个分析崩溃日志的小提示作为结束：
- 不止关注崩溃本行，结合上下文进行分析。
- 不止关注崩溃线程，要结合其他线程的堆栈信息。
- 通过多个崩溃日志，组合分析。
- 使用地址定位和野指针工具重现内存问题。
