源自：字节跳动团队

感谢字节跳动团队的分享， 本文意在分享此类开发崩溃知识，如有涉及侵权，请联系我删除

ARC 环境下在多线程中执行赋值代码可能会产生野指针，导致 EXC_BAD_ACCESS 崩溃。
这种崩溃发生的概率很低，在开发和灰度阶段即使执行到相应代码也很难崩溃，因此容易遗漏到正式环境。在上亿级用户的 App 往往会成为 Top 问题，对指标造成影响，并且很难排查。
今日头条在治理 Crash 的过程中彻底解决了数十个此类崩溃，发现其具有一定共性。本文详细分析崩溃发生的过程，以及总结了容易出现问题的场景，希望在大家遇到此类问题时能提供一些思路。

1. 原理

Objective-C 对象的赋值过程包含创建新值、保留旧值、加载新值、释放旧值四步。相比 MRC，ARC 环境中编译器会自动插入保留与释放旧值的步骤：

• • image.png
• • image.png
• • image.png
• • image.png

objc_release 会减小对象的引用计数，减小到 0 时对象就会被销毁，假如这时有其它线程正在使用这个对象，那么使用对象的线程就很可能发生崩溃。

2. 崩溃场景

Demo设计在 B 线程中释放 A 线程创建的对象使 C 线程崩溃：

• • image.png

复现过程：

• • image.png

2. A 线程先创建初始值 _instance

• A 线程执行到 _instance = x0， 创建了新值并赋给 _instance；此时 _instance 引用计数为 1；

3. B、C 线程读取到 A 线程创建的初始值 _instance

• B、C 线程分别执行到 x1 = _instance 时，从 _instance 中读到线程 A 创建的对象，保存到各自的上下文中；_instance 引用计数仍为 1；

4. B 线程释放 _instance

• B 线程执行 objc_release(x1) 后会释放 _instance；_instance 引用计数变为 0，被销毁；

5. C 线程访问 _instance

• C 线程执行到 objc_release(x1) 时访问 _instance；由于 _instance 已经被销毁，访问时会发生崩溃。

3. 崩溃原因

如下图，为什么会发生 EXC_BAD_ACCESS 崩溃？

• • image.png

ldr x17, [x2, #0x20] 指令认为寄存器 x2 中存放的是地址，将该地址和 0x20 相加获得一个新地址，再从新地址中读取 8 字节存放到 x17 中。
本例中可以分析出寄存器 x2 存放的是 Class 的地址，x2+0x20 是 Class 的成员变量 bits 的地址，这个地址是 0x00000007374040e0。从这个地址中读值时操作系统发现它是非法内存地址，从而产生 EXC_BAD_ACCESS 异常并报出这个错误地址。
附：Class 的结构体及成员变量的偏移

• • image.png

为什么 Class->bits 的地址会是 0x00000007374040e0 ，这个非法地址是怎么来的？

_instance 对象被销毁后，内存被系统随机改写，通过崩溃截图中 lldb 打印的日志可知：

对象的 ISA 位置存放的随机值是 0x000010d7374040c0

• Class = ISA & ISA_MASK = 0x00000007374040c0
• Class->bits = 0x00000007374040c0 + 0x20 = 0x00000007374040e0
• ISA 是随机值，那么 Class、Class->bits 也都是随机值，很容易是一个非法的内存地址，访问非法内存地址就会产生 EXC_BAD_ACCESS 异常。

在执行 objc_release 函数之前 _instance 就已经销毁了，为什么执行到 ldr x17, [x2, #0x20] 这一行指令时才发生崩溃，之前没有崩溃？

EXC_BAD_ACCESS 异常发生在访问非法内存地址时。在 ldr x17, [x2, #0x20] 之前仅有 ldr x16, [x0] 中使用方括号 [] 访问了 x0 中存储的地址。此时 x0 中存储的是 _instance 的地址，_instance 销毁后对象的内存被系统随机改写，而 x0 中的地址是之前就存进来的合法地址，访问合法地址不会出现异常。

4.更多崩溃场景

上述崩溃发生在 objc_release 堆栈中，但实际可能发生在任意堆栈，这与 _instance 使用的场景有关。下面构造了一些常见的崩溃堆栈，感兴趣的读者可以参照复现。

4.1崩溃在 objc_retain 中

• • image.png
• • image.png

崩溃原因：_instance 作为参数传递到 bar 函数，在函数开始执行时会保留参数 objc_reatin(_instance)，结束执行时会释放参数objc_release(_instance)。若保留参数时 _instance 已被其它线程销毁，就会导致崩溃在 objc_reatin 中。

4.2 崩溃在 objc_msgSend 中

• • image.png
• • image.png

崩溃原因：第 7 行代码向 _instance 发送了 isEqual: 消息，在执行到崩溃指令 ldr x11,[x16, #0x10] 时，寄存器 x16 存放的是 _instance 的 Class，[x16, #0x10] 指令想要读取 Class->cache，进而从 cache 中寻找缓存的方法。_instance 销毁后 ISA、Class、Class->cache 会成为随机值，如果 Class->cache 是非法地址，在执行 [x16, #0x10] 时就会崩溃。

4.3 崩溃在 objc_autoreleasePoolPop 中

• • image.png
• • image.png

崩溃原因：若对象使用非 new/alloc/copy/mutableCopy 开头的接口创建，并且不满足 Autorelease elision [3] 策略，会被添加到自动释放池中。本例创建的 _instance 被添加到子线程的自动释放池中，子线程任务执行完成后会对池中的对象 pop，依次调用 objc_release 进行释放，若次此时 _instance 已在其它线程中销毁，就会发生崩溃。

4.4 EXC_BREAKPOINT 崩溃

• • image.png
• • image.png

崩溃原因：-[NSString stringWithFormat:@"%@",_instance] 会调用 objc_opt_respondsToSelector 函数并将 _instance 作为参数传入。在 objc_opt_respondsToSelector 函数发生崩溃前，x16 存储的是参数 _instance 的 Class。

指针认证 [4] 相关的指令会使 x16 寄存器与 x17 寄存器相等，然后用 xpacd x17 对 x17 寄存器中高位清零，再比较 x16 与 x17，不相等则执行 brk 指令触发 EXC_BREAKPOINT 异常。xpacd 对合法指针清零不会改变指针的值，不会执行 brk 指令产生异常。当参数被销毁后，x16 可能被改写为非法指针并赋给 x17，xpacd x17 对非法指针高位清零会改变 x17，使 x17 不等于 x16，导致 EXC_BREAKPOINT 异常。

5. 常见典型业务场景

5.1 场景一 对全局变量赋值

• • image.png

这段代码定义了全局变量 geckoSettingDict，并在在一个懒加载方法中对它初始化。最初这段代码正常运行在于 A 业务中，后面被 B 业务拷贝走，B 业务存在多线程调用的场景，在 geckoSettingDict 未初始化时，多个线程可以同时进入 if (geckoSettingDict == nil) 对 geckoSettingDict 赋值，导致 geckoSettingDict 被提前销毁产生崩溃。

由于使用了 dictionaryWithContestOfFile: 接口初始化，geckoSettingDict 会被添加到自动释放池中，导致崩溃发生在 objc_autoreleasePoolPop 堆栈里，很难追查。这个问题困扰头条半年之久，最终借助字节内部 APM 提供的线上工具定位到原因：

• • image.png

小结：

• 这类问题常见于开发者设计了全局变量，并在对外暴露的接口中对全局变量进行赋值，开发者预期变量只会初始化一次，但实际接口被调用的环境不可控
• 修复建议：使用 dispatch_once，保证全局变量只被赋值一次。

5.2 场景二 对属性赋值

• • image.png

某类设计了属性 extraParam 用于保存透传参数，并在 updateExtraParams: 方法中更新该属性。最初 updateExtraParams: 也在多线程中被调用，但没有造成很大影响，某次需求增大了它被同时调用的概率，引发了大面积的崩溃。

小结：

• 这类问题常见于类向外部提供了接口来更新成员变量，但接口被调用的环境不可控。
• 单例的属性更容易被外界访问，更容易在多线程下出现赋值，因此这类问题也最多。
• 修复建议：涉及多线程修改的属性，使用 atomic 修饰。

5.3 场景三 属性懒加载

• • image.png

某类在懒加载方法中对 _interceptUrls 赋值，在 addADparamsToRequest 方法中调用 self.interceptUrls 触发懒加载。由于业务环境复杂，addADparamsToRequest 在主线程、网络回调线程、通知线程等多个场景中被调用，多线程下同时对 _interceptUrls 赋值导致它被提前销毁，产生崩溃。

修复办法是将 _interceptUrls 的初始化放在 init 方法中，保证它只被赋值一次。

• • image.png

案例2

image.png

某类在懒加载方法中对 _userCache 赋值，在 cacheUserInfo:、removeCachedUserInfo:等 4 个方法中都调用了 self.userCache 触发懒加载，这 4 个方法可能同时被多个线程调用，很容易出现多线程环境下对 _userCache 赋值，导致它提前销毁。解决办法是将 _userCache 初始化放在 init 中，保证它只会被赋值一次。

小结：

• 这是类场景比上述场景都更加隐蔽，在设计懒加载方法时要考虑触发懒加载的方法是否会在多线程环境中被调用。
• 修复建议：如果懒加载属性会被多线程访问到，就不要使用懒加载，直接在 init 方法中初始化，保证赋值的代码只会被一个线程访问。

6.如何分析此类崩溃？

• 有业务代码堆栈的崩溃，可以通过反汇编推断出具体崩溃的对象；在工程中检索对该对象赋值的代码是否存在多线程调用，如果存在就基本可以确认崩溃原因是多线程赋值导致。
• 纯系统堆栈的崩溃，如发生在 objc_autoreleasePoolPop 堆栈的崩溃。通过反汇编只能推断出是某个对象被 over-release 了，无法推断出具体是哪个对象。字节内部的同学可以使用 APM 提供的 Zombie、GWPASan、Coredump 等线上工具 [5]进行排查；如果没有线上工具，需要找到与该崩溃同一版本/时间段上涨的其它野指针崩溃，它们有可能是同一个原因导致的，从有业务代码堆栈的崩溃入手去排查。

7. 参考：文献

[1] Objective-C Automatic Reference Counting (ARC) — Clang 16.0.0git documentation (https://clang.llvm.org/docs/AutomaticReferenceCounting.html#semantics)

[2] LLDB Tutorial (https://opensource.apple.com/source/lldb/lldb-310.2.36/www/tutorial.html)

[3] WWDC22: Improve app size and runtime performance - 掘金 (https://juejin.cn/post/7135344206939160612#heading-5)

[4] ARM-指针认证 (https://www.jianshu.com/p/62bf046b7701)

[5] 字节跳动如何系统性治理 iOS 稳定性问题 (https://juejin.cn/post/7034418275728097288)