Xcode 崩溃日志解读：如何定位 EXC_BREAKPOINT (SIGTRAP) 错误？

2024-08-09 04:33:34

Xcode 崩溃日志解读：精准定位 Crash 代码位置

在 iOS 开发过程中，应用程序崩溃是开发者们难以避免的家常便饭。而 Xcode 中那一堆堆的崩溃日志，对于许多开发者来说，如同天书般难以解读。如何才能快速、准确地定位到导致崩溃的代码行，成为困扰许多开发者的难题。

本文将以 EXC_BREAKPOINT (SIGTRAP) 类型的崩溃为例，带您一步步解析如何从 Xcode 崩溃日志中抽丝剥茧，找到问题根源，并提供一些实用的调试技巧。最终您将有能力像经验丰富的开发者一样，轻松化解崩溃问题。

崩溃日志：你的应用“黑匣子”

想象一下，崩溃日志就像飞机失事后的黑匣子，记录着崩溃发生时的关键信息。学会解读这些信息，就如同拥有了破案的关键线索。

让我们先来分析一段典型的 EXC_BREAKPOINT (SIGTRAP) 崩溃日志，从中挖掘出有价值的信息：

Incident Identifier: B6FD1E1C-A75D-4431-B18B-25A1F7B861A2
CrashReporter Key:   af5e202a7a32d28118908a237f123c7838f95c4d
Hardware Model:      xxx
Process:             YourAppName [15898]
Path:                /private/var/containers/Bundle/Application/248A2E10-A53D-4C3B-A7A1-8A82D2E4442D/YourAppName.app/YourAppName
Identifier:          com.yourcompany.YourAppName
Version:             1.0 (1)
AppStoreTools:       14A400
Code Type:           ARM-64 (Native)
Role:                Foreground
Parent Process:      launchd [1]
Coalition:           com.yourcompany.YourAppName [762]

Date/Time:           2023-12-19 10:05:15.3531 +0800
Launch Time:         2023-12-19 10:04:52.9667 +0800
OS Version:          iPhone OS 16.2 (20C65)
Release Type:        User
Baseband Version:    2.00.03
Report Version:      104

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x00000001a8fcbc34
Termination Signal: Trace/BPT trap: 5
Termination Reason: Namespace SIGNAL, Code 0x5
Terminating Process: exc handler [15898]
Triggered by Thread:  65

Thread 0 name:
Thread 0:
<...>

Thread 65 name:
Thread 65 Crashed:
0   CoreAutoLayout                      0x1c209b65c -[NSISEngine _AssertAutoLayoutOnAllowedThreadsOnly] + 328 (NSISEngine.m:123)
1   CoreAutoLayout                      0x1c209b418 -[NSISEngine _optimizeWithoutRebuilding] + 164 (NSISEngine.m:101)
2   UIKitCore                           0x19e992d50 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2968 (UIView.m:17773)
3   QuartzCore                          0x1a0496774 <redacted> + 276
4   QuartzCore                          0x1a04e3b88 <redacted> + 292
5   CoreFoundation                      0x1a789a2c8 <redacted> + 344
6   CoreFoundation                      0x1a7899b7c <redacted> + 1116
7   CoreFoundation                      0x1a7898750 <redacted> + 1468
8   CFNetwork                           0x1a7dd6d80 <redacted> + 1084
9   CFNetwork                           0x1a7e14e4c <redacted> + 156
10  libdispatch.dylib                   0x1a74d578c <redacted> + 56
11  libdispatch.dylib                   0x1a74d9444 <redacted> + 204
12  libdispatch.dylib                   0x1a74d1a10 <redacted> + 964
13  libdispatch.dylib                   0x1a74d1108 <redacted> + 176
14  libsystem_pthread.dylib             0x1e1804230 <redacted> + 16
15  libsystem_pthread.dylib             0x1e1800024 <redacted> + 104

Thread 66 name:
<...>

Thread 67 name:
<...>

Thread 68 name:
<...>

不用被这密密麻麻的字符吓倒，让我们来逐一解读：

Exception Type : EXC_BREAKPOINT (SIGTRAP) 表明这是一个断点异常，通常是由于触发了断言、执行了非法指令或者被调试器主动中断导致的。
Exception Codes :
- 0x0000000000000001: 表示这是一个通用的 TRAP 类型异常。
- 0x00000001a8fcbc34: 这个地址可能指向了发生崩溃的指令或者数据，但由于缺少符号化信息，无法直接解读。
Terminating Process : exc handler [15898] 指出崩溃发生在异常处理程序中，进程号为 15898。
Triggered by Thread : 65 表明崩溃是由线程 65 触发的。
Last Exception Backtrace : 这是最重要的部分，它展示了崩溃发生时函数调用的堆栈信息。每一行代表一个函数调用，从上到下表示调用顺序，最上面的一行是崩溃发生时所在的函数。

顺藤摸瓜：定位 Crash 代码行

通过分析崩溃日志的堆栈信息，我们就像侦探一样，顺着函数调用链条逐步排查，最终找到罪魁祸首：

崩溃发生在 CoreAutoLayout 框架中，与自动布局引擎相关。
-[NSISEngine _AssertAutoLayoutOnAllowedThreadsOnly] 方法触发了断言，导致程序中断。这个方法名已经明确提示我们，问题出在 UI 操作的线程安全上。
调用堆栈中包含 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] 等方法，暗示问题可能与视图布局更新相关。

为了精确定位代码位置，我们需要将崩溃日志符号化，即将地址信息转换成可读的函数名和行号。通常情况下，Xcode 会在编译项目时自动生成符号化文件 (dSYM)。

符号化崩溃日志的方法:

Xcode 自动符号化 : 如果您使用 Xcode Organizer 窗口中的 Crashes Organizer，Xcode 会尝试自动符号化崩溃日志，您只需查看对应崩溃日志即可。
命令行工具 symbolicatecrash : 您可以使用 Xcode 自带的命令行工具 symbolicatecrash 手动符号化崩溃日志。
第三方工具 : 一些第三方崩溃分析平台，例如 Firebase Crashlytics、Bugly 等，也提供了崩溃日志符号化和分析功能，更加方便快捷。

成功符号化后，您将能够在堆栈信息中看到具体的函数名和行号，例如：

3   CoreAutoLayout                  0x1c209b65c -[NSISEngine _AssertAutoLayoutOnAllowedThreadsOnly] + 328 (NSISEngine.m:123)

这表明崩溃发生在 NSISEngine.m 文件的第 123 行，_AssertAutoLayoutOnAllowedThreadsOnly 方法中。

对症下药：常见原因及解决方案

根据崩溃日志的分析结果，我们就可以对 EXC_BREAKPOINT (SIGTRAP) 崩溃的原因进行合理推测了：

在非主线程更新 UI : 自动布局引擎的更新操作必须在主线程执行，如果在子线程中修改了约束或者视图的布局属性，就可能触发断言导致崩溃。
- 解决方案 : 将所有 UI 更新操作都放到主线程执行，可以使用 DispatchQueue.main.async 将代码块提交到主队列。
```
DispatchQueue.main.async {
    // 在这里执行 UI 更新操作
}
```
约束冲突 : 自动布局系统无法同时满足所有约束条件，导致布局引擎无法计算出正确的布局。
- 解决方案 : 仔细检查代码中添加的约束，确保它们之间没有冲突。可以使用 Xcode 的视图调试器或者打印视图的约束信息来辅助排查问题。
```
print(yourView.constraints)
```
约束添加时机错误 : 在视图尚未添加到视图层次结构中时就添加约束，或者在 layoutSubviews 方法之外修改约束，都可能导致问题。
- 解决方案 : 确保在合适的时机添加和修改约束。例如，可以在 viewDidLoad 方法中添加初始约束，在 viewDidLayoutSubviews 方法中根据需要更新约束。
```
override func viewDidLoad() {
    super.viewDidLoad()
    // 添加初始约束
}

override func viewDidLayoutSubviews() {
    super.viewDidLayoutSubviews()
    // 更新约束
}
```

工欲善其事：高效调试技巧

除了上述分析方法外，以下调试技巧也能帮助您更快地找到崩溃原因：

添加断点 : 在 _AssertAutoLayoutOnAllowedThreadsOnly 方法或者其他可疑代码处添加断点，程序运行到断点处会自动暂停，您可以观察程序运行状态，查看变量的值以及线程信息。
打印日志 : 在代码关键位置打印日志，输出变量值、函数调用信息等，帮助定位问题。
```
print("进入函数：\(#function)")
print("变量值：\(yourVariable)")
```
使用 Instruments : 使用 Xcode 自带的性能分析工具 Instruments，可以检测主线程阻塞、多线程问题等，辅助排查与线程相关的崩溃问题。