iOS crash 报告分析系列 - 看懂 crash 报告的内容

在日常工作中，开发者最怕的应该就是线上的崩溃了。线上的崩溃不像我们开发中遇到的崩溃，可以在 Xcode 的 log 中直观的看到崩溃信息。

不过，线上的崩溃也并不是线索全无，让我们卖虾的不拿秤 -- 抓瞎。

每当 App 发生崩溃时，系统会自动生成一个后缀 ips 的崩溃报告。我们可以通过崩溃报告来进行问题定位。但崩溃报告的内容繁多，新手看很容易一脸懵。所以本文先讲解一下报告中各字段的含义，后面再说报告符号化。

废话不多说，让我们开始吧！

前期准备

首先，报告解读我们需要先生成一个 crash 报告。

1、新建一个项目，在 ViewController 中写下面的代码：

NSString *value;
NSDictionary *dict = @{@"key": value}; // 字典的 value 不可为 nil，所以会崩溃

2、在真机上运行项目，然后去设置 - 隐私与安全性 - 分析与改进 - 分析数据，拿去生成的 crash 报告（报告的名字与项目名字一致，比如我的项目名为：CrashDemo，崩溃报告的名则为：CrashDemo-2023-05-30-093930.ips）。

注意：连着 Xcode 运行时不会产生崩溃报告，需要真机拔掉数据线再次运行 app 才会生成崩溃报告。

拿到报告，接下来就是解读了。

报告内容解读

官网的示例图：

Header

首先来看 Header：

Incident Identifier: 9928A955-FE71-464F-A2AF-A4593A42A26B
CrashReporter Key:   7f163d1c67c5ed3a6be5c879936a44f10b50f0a0
Hardware Model:      iPhone14,5
Process:             CrashDemo [45100]
Path:                /private/var/containers/Bundle/Application/6C9D4CF7-4C16-4B50-A4A5-389BED62C699/CrashDemo.app/CrashDemo
Identifier:          cn.com.fengzhihao.CrashDemo
Version:             1.0 (1)
Code Type:           ARM-64 (Native)
Role:                Foreground
Parent Process:      launchd [1]
Coalition:           cn.com.fengzhihao.CrashDemo [3547]

Date/Time:           2023-05-30 09:39:29.6418 +0800
Launch Time:         2023-05-30 09:39:28.5579 +0800
OS Version:          iPhone OS 16.3.1 (20D67)
Release Type:        User
Baseband Version:    2.40.01
Report Version:      104

Header 主要描述了目标设备的软硬件环境。比如上图可以看出：是 iphone 14 的设备，系统版本是16.3，发生崩溃的事件是 2023-05-30 09:39:29 等等。

需要注意的是 Incident Identifier 相当于当前报告的 id，报告和 Incident Identifier 是一一对应的关系，绝对不会存在两份不同的报告 Incident Identifier 相同的情况。

Exception information

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000

这一部分主要是告诉我们 app 是因为什么错误而导致的崩溃，但不会包含完整的信息。

可以看到当前的 Type 为：EXC_CRASH (SIGABRT)，这代表当前进程因收到了 SIGABRT 信号而导致崩溃，这是一个很常见的类型，字典 value 为nil或者属于越界等都会是此类型。更多的 Exception Type 解释请参见此处。

Diagnostic messages

Application Specific Information:
abort() called

操作系统有时包括额外的诊断信息。此信息使用多种格式，具体取决于崩溃的原因，并且不会出现在每个崩溃报告中。

本次的崩溃原因是因为调用了 abort() 函数。

接下来，就是报告的重点了。

Backtraces

这部分记录了当前进程的线程的函数调用栈，我们可以通过调用栈来定位出问题的代码。

崩溃进程的每一条线程都会被捕获成回溯。回溯会展示当前线程被中断时的线程的函数调用栈。如果崩溃是由于语言异常造成的，会额外有一个Last Exception Backtrace，位于第一个线程之前。关于 Last Exception Backtrace 的详细介绍请看这里

比如我们示例中的崩溃就是由于语言异常造成的，所以崩溃报告中会有 Last Exception Backtrace。

Last Exception Backtrace:
0   CoreFoundation                	       0x191560e38 __exceptionPreprocess + 164
1   libobjc.A.dylib               	       0x18a6f78d8 objc_exception_throw + 60
2   CoreFoundation                	       0x191706078 -[__NSCFString characterAtIndex:].cold.1 + 0
3   CoreFoundation                	       0x1917113ac -[__NSPlaceholderDictionary initWithCapacity:].cold.1 + 0
4   CoreFoundation                	       0x19157c2b8 -[__NSPlaceholderDictionary initWithObjects:forKeys:count:] + 320
5   CoreFoundation                	       0x19157c158 +[NSDictionary dictionaryWithObjects:forKeys:count:] + 52
6   CrashDemo                     	       0x104a69e0c -[ViewController touchesBegan:withEvent:] + 152
.... 中间内容省略
25  CrashDemo                     	       0x104a6a0c4 main + 120
26  dyld                          	       0x1afed0960 start + 2528

以下是上述每一列元素的含义：

• 第一列：栈帧号。堆栈帧按调用顺序排列，其中帧 0 是在执行暂停时正在执行的函数。第 1 帧是调用第 0 帧函数的函数，依此类推
• 第二列：包含正在执行函数的二进制包名
• 第三列：正在执行的机器指令的地址
• 第四列：在完全符号化的崩溃报告中，正在执行的函数的名称。出于隐私原因，函数名称有时限制为前 100 个字符
• 第五列（+ 号后面的数字）：函数入口点到函数中当前指令的字节偏移量

通过第 6 行我们可以推断出问题是由 NSDictionary 引起的。

但大部分时候我们得到的报告都是未符号化的，我们需要对报告进行符号化来获得更多的信息。关于符号化的相关内容可以看这里。

Thread state

Thread 0 crashed with ARM Thread State (64-bit):
x0: 0x0000000000000000   x1: 0x0000000000000000   x2: 0x0000000000000000   x3: 0x0000000000000000
...中间内容省略
far: 0x00000001e4d30560  esr: 0x56000080  Address size fault

崩溃报告的线程状态部分列出了应用程序终止时崩溃线程的 CPU 寄存器及其值。

Binary images

0x1cf074000 -        0x1cf0abfeb libsystem_kernel.dylib arm64e  <c76e6bed463530c68f19fb829bbe1ae1> /usr/lib/system/libsystem_kernel.dylib
       ...中间内容省略
       0x18b8ca000 -        0x18c213fff Foundation arm64e  <e5f615c7cc5e3656860041c767812a35> /System/Library/Frameworks/Foundation.framework/Foundation

以下是上述每一列元素的含义：

• 第一列：二进制镜像在进程中的地址范围
• 第二列：二进制镜像的名称
• 第三列：操作系统加载到进程中的二进制映像中的 CPU 架构
• 第四列：唯一标识二进制映像的构建 UUID。符号化崩溃报告时使用此值定位相应的 dSYM 文件
• 第五列：二进制文件在磁盘上的路径

至此，报告上的所有 section 都已经解读完。希望大家看完这篇文章后，再分析崩溃日志的时候能更加得心应手。