欢迎光临散文网 会员登陆 & 注册

我给 iOS 系统打了个补丁——修复 iOS 16 系统键盘重大 Crash

2023-09-08 21:32 作者:支付宝体验科技  | 我要投稿


🙋🏻‍♀️ 编者按：本文作者是蚂蚁集团客户端工程师巴乐，通过逆向分析发现了 iOS 16 系统键盘存在重大 Bug，可能导致使用到键盘的业务场景出现严重 Crash。在支付宝 App 近期版本 10.5.16.6000 上，巴乐用汇编重新实现了一套 iOS 16 系统键盘 tryLock 方法后，问题得到完全修复，该版本上的对应 Crash 已降到 0。本文记录了该问题解决的完整过程，包括问题发现、分析、修复以及验证，欢迎查阅与交流～

背景

在蚂蚁集团内部，支付宝技术部及蚂蚁终端技术委员会联合发起了“技术挑战英雄榜”活动，通过张榜一系列技术难题，寻找那些富有激情、敢于挑战的同学，揭榜解题，攻克顽疾！

在难题榜中，有蚂蚁内部同学张榜反馈了 iOS 支付宝 App Top 1 的 iOS 16 键盘 Crash（下文可简称“键盘 Crash“），即下图 1 的 issue 1。该 Crash 量级大且持续时间长，线下不好复现又不好排查，对线上业务影响很大，急需攻坚。

本人基于对客户端运行时技术的浓厚兴趣，揭榜领题，挑战解决该 Crash。

图 1 蚂蚁内部的技术挑战英雄榜

原始信息

Crash 信息

Crash 日志关键信息如下：

提取 Crash 关键信息（后续分析基于该信息）：

  • 摘要信息：iPhone 12 Pro Max（Hardware Mode: iPhone13 4）、iOS 16.6、支付宝App 10.5.0.6000 版本、Crash 直接原因是读内存地址0x2ab3106e0异常（一般读内存报错为SEGV_MAPERR，写内存报错为EXC_BAD_ACCESS）

  • Crash 关键函数：0x00000001a5183a7c _objc_retain、0x00000001aed4d4d4 -[UIKeyboardTaskQueue performDeferredTaskIfIdle]、0x00000001ae533148 -[UIKeyboardTaskQueue continueExecutionOnMainThread]

  • Thread State：通用寄存器和浮点寄存器快照，用于查看运行时变量值及更深入的逻辑推测；

  • Binary Images：各 Image （运行时可执行指令的文件）二进制布局在内存起始位置及结束地址，起始位置可做基准，可用于计算 Crash 时的某指令地址相对于所属 Image 起始地址的偏移。

量级及分布

键盘 Crash 日 PV 一直处于大几百次，持续至少半年多，从操作系统版本分布来看仅在 iOS 16 上出现（覆盖所有机型）。

图 2 键盘 Crash 日 PV 趋势图


图 3 键盘 Crash 在不同机型及操作系统的量级分布


信息小结

从 Crash 日志栈顶的 objc_retain 函数关键字和量级分布情况来看，该 Crash 很可能是由 iOS 16 系统键盘控件的内存管理异常导致。

分析推演

下文分析推演涉及的知识点或技能：

  1. 使用软件：Sublime Text、Xcode 及自带的lldb命令，包括b、c、bt、frame select、di、image list、p/x、po、x/1b；

  2. 汇编能力：Arm64 寄存器说明 [1] 、Arm64 汇编指令集说明 [2] ;

  3. 脚本工具：otool、自研脚本fetch_class_text_from_all.sh；

  4. 关键类：UIKeyboardTaskQueue 键盘核心类、NSConditionLock条件状态锁（具体使用见官方文档 [3] ）；

  5. 依赖模块：蚂蚁自研的DebugKit.framework（后续考虑对外输出）调试模块。

一、看现场，从 Crash 点开始

——计算 Crash 函数的偏移 

因 iOS 运行时加载到内存的 Image 的起始地址是动态的（对应 Binary Images 列表中的起始地址），但某指令地址与所属 Image 的起始地址的偏移是固定的，所以可根据该偏移来查看 Crash 时是哪条指令。

  • 0x00000001a5183a7c _objc_retain所属的libobjc.A.dylib的起始地址是0x00000001a5180000，所以相对偏移 = 0x00000001a5183a7c - 0x00000001a5180000 = 0x3a7c

  • 0x00000001aed4d4d4 -[UIKeyboardTaskQueue performDeferredTaskIfIdle]所属的UIKitCore的起始地址是0x00000001ae166000，所以相对偏移 =0x00000001aed4d4d4 - 0x00000001ae166000 = 0xbe74d4

二、模拟现场，寻找蛛丝马迹

—— Xcode 设置断点模拟现场

  1. 为模拟与 Crash 时一样的现场，需找一台与 Crash 日志中一致的设备，即 iOS 16.6 的iPhone 12 Pro Max（Hardware Mode: iPhone13 4），只有这样在下文中断点时的函数栈以及各函数偏移对应的指令才能与 Crash 日志中的完全对上。

  2. 将找到的设备与 Mac 连接并用 Xcode 启动 App（可用下文附件中 Demo 关键代码调试）。

  3. 从上述计算出的关键函数的偏移加上所属 Image 的起始地址，模拟出 Crash 时运行的函数栈，具体操作如下图 4。

图 4 设置断点模拟现场

从图 4 的第 11 步可知 Crash 的直接原因是objc_retain的对象野指针了，导致读取内存异常而触发 Crash。

图 5 查看上一层函数栈

从图 5 可知两点：

  1. 先后调用关系是-[UIKeyboardTaskQueue performDeferredTaskIfIdle] -> -[UIKeyboardTaskQueue promoteDeferredTaskIfIdle]（该函数在 Crash 函数栈中未出现，所以只有模拟现场才能发现）-> objc_retain

  2. UIKeyboardTaskQueue类有个NSMutableArray类型的成员变量持有UIKeyboardTaskEntry对象（从图 5 中第 8 步的输出得出），而 Crash 的直接原因就是获取该数组index = 0的UIKeyboardTaskEntry对象后，执行objc_retain该对象 Crash ，所以异常的原因需要从对该数组的读写排查。

小结：UIKeyboardTaskQueue类的NSMutableArray类型的成员变量是关键数组（在实例对象偏移 0x20 的位置），怀疑是多线程读写该数组导致的。那么该成员变量名是啥，UIKeyboardTaskQueue类又是如何保证安全使用该数组的呢？

三、全面排查，收集更多信息

—— 获取 UIKeyboardTaskQueue 类的全部信息 

借助蚂蚁自研的 DebugKit.framework 调试模块可在运行时导出 UIKeyboardTaskQueue 类所有的实例方法、类方法、property 和 ivars 成员变量。

图 6 获取 UIKeyboardTaskQueue 类的基础信息

从图 6 可知两点：

  1. UIKeyboardTaskQueue 的成员变量  _deferredTasks 的类型是 NSMutableArray （在实例对象起始地址偏移 0x20 的位置，从图 6 中第 6 点可知）就是上述提到关键数组。野指针一般是有多线程读写对象导致的，对_deferredTasks 数组读写时应该是有锁来控制的，该类中类型为 NSConditionLock 的成员变量 _lock（在实例对象偏移 0x10 的位置，从图 6 中第 5 点可知）与 _deferredTasks 是啥关系？

  2. 发现该类的 property 列表只有 executionContext 和 activeOriginator，不包含 deferredTasks 和 lock，所以对 _deferredTasks 和 _lock（类的成员变量名一般是在 property 名前多加前缀“_”）的所有读写全在该类中，不存在其他类直接引用，也就是 Crash 相关的全部逻辑都在 UIKeyboardTaskQueue 类中，所以破案的边界也划清楚了，圈定范围。将 UIKeyboardTaskQueue 类的所有方法的汇编都导出来查看。

图 7 获取 UIKeyboardTaskQueue 类的所有方法实现

图 7 中第 2 步涉及的 fetch_class_text_from_all.sh 见下文附件中脚本源码。 

小结：通过分析圈定排查范围在 UIKeyboardTaskQueue 类内，借助脚本可一键导出其所有方法的汇编，为进一步研究 _deferredTasks 和 _lock 的关系做基础。

四、理清关系，找到突破口

—— 研究 _deferredTasks 和 _lock 关系 

理清以下重要的两个关系：

  1. _deferredTasks 角度：UIKeyboardTaskQueue 类对 _deferredTasks 的多线程读写是如何保证安全的，哪些方法有用到，与 _lock 又是什么关系？

  2. _lock 角度：UIKeyboardTaskQueue 类对 _lock 又是如何使用的，哪些方法有用到，加锁和解锁是否配对？

deferredTasks 角度

图 7 第 2 步导出的UIKeyboardTaskQueue的所有方法实现都是汇编的，为理清对_deferredTasks对象的所有读写有哪些指令，分别在哪些方法中（UIKeyboardTaskQueue实例对象偏移 0x20 的位置，该地址下存储的 8 字节地址才是_deferredTasks对象），需要在文件中全文搜索正则表达式x.{1,2}, #0x20筛选出所有引用_deferredTasks的指令以及所属方法，操作如下图 8（Sublime Text）。

图 8 全文搜索正则表达式的样例

在汇编层面，面向对象语言中方法的第一个入参是self（C++ 称this，Objective-C 称self），存放在x0寄存器上，所以仅筛选出偏移是从方法入参时的x0或x0备份（如mov x19, x0，x19就是备份了x0的值）开始的，最后整理出所有UIKeyboardTaskQueue对_deferredTasks有引用并读写的指令及所属方法，如下。

注：

  • 一般面向过程语言的代码块称为函数，而面向对象语言的代码块称为方法，为避免文章的混用造成困扰，这里特别说明。

  • 下列部分的“读”或“写”是指获取到_deferredTasks对象后，对该对象是读操作还是写操作。

读_deferredTasks的方法有 6 个：

  1. -[UIKeyboardTaskQueue isEmpty]

  2. -[UIKeyboardTaskQueue finishExecution]

  3. -[UIKeyboardTaskQueue promoteDeferredTaskIfIdle]

  4. -[UIKeyboardTaskQueue continueExecutionOnMainThread]

  5. -[UIKeyboardTaskQueue waitUntilAllTasksAreFinished]

  6. -[UIKeyboardTaskQueue init]

写_deferredTasks的方法有 4 个：

  1. -[UIKeyboardTaskQueue promoteDeferredTaskIfIdle]

  2. -[UIKeyboardTaskQueue addDeferredTask:]

  3. -[UIKeyboardTaskQueue init]

  4. -[UIKeyboardTaskQueue .cxx_destruct]

_lock 角度

在文件中全文搜索正则表达式x.{1,2}, #0x10筛选出所有引用_lock的指令以及所属方法，操作类似上述的_deferredTasks；从上可知，UIKeyboardTaskQueue类对_lock的使用封装成 4 个方法（忽略init创建和.cxx_destruct销毁的两个方法，该两方法不会有并发问题），也就是方法使用_lock必定会调用这 4 个方法。

解锁方法有 1 个：

  1. -[UIKeyboardTaskQueue unlock]

加锁方法有 3 个：

  1. -[UIKeyboardTaskQueue lock]

  2. -[UIKeyboardTaskQueue lockWhenReadyForMainThread]

  3. -[UIKeyboardTaskQueue tryLockWhenReadyForMainThread]

串联关系，发现 Bug

串联上述_deferredTasks和_lock两个角度的方法调用（忽略init创建和.cxx_destruct销毁的两个方法），从原汇编的关键方法中列出简版的关系描述，如下图 9。

图 9 串联 _deferredTasks 和 _lock 的关系

为方便理清锁的对应关系，图 9 中用红色表示加锁，绿色表示解锁，从中可知：

  1. 对_deferredTasks的关键读写的方法内是有 1 个加锁和 1 个解锁对应的，预期是多线程下保护读写的安全性；

  2. 即使不读写_deferredTasks的方法内上也是有 1 个加锁和 1 个解锁对应的，用于多线程下保护其他成员变量的读写安全性；

  3. 发现问题，有 Bug：-[UIKeyboardTaskQueue continueExecutionOnMainThread]方法内的0000000189466ff8 bl _objc_msgSend$tryLockWhenReadyForMainThread这行指令执行是返回BOOL类型的，即加锁成功为YES，加锁失败为NO。（参看图 6 中-[UIKeyboardTaskQueue tryLockWhenReadyForMainThread]的方法签名为typeEncoding=B16@0:8，即返回为BOOL类型）；如该行指令尝试加锁但失败了，不会直接return，还会继续执行红色框内的指令并做解锁操作，会导致多线程下UIKeyboardTaskQueue类的加锁和解锁的功能不配对，也就存在锁失效的情况。

小结：-[UIKeyboardTaskQueue continueExecutionOnMainThread]方法内有 Bug，导致存在锁失效的情况，猜测在多线程下并发读写_deferredTasks时就会偶现 Crash。

五、重新推演，确定根因

推演图

图 10 重新推演键盘 Crash 过程

按时间轴重新推演键盘 Crash 过程：

  • T0：Thread A加锁成功后执行指令bl _objc_msgSend$addObject:添加对象A到数组_deferredTasks。同时，因为Main Thread执行指令bl _objc_msgSend$tryLockWhenReadyForMainThread失败后继续执行指令bl _objc_msgSend$unlock，使得Thread B也加锁成功后执行指令bl _objc_msgSend$addObject:添加对象B到数组_deferredTasks，导致出现多线程同时写入数组_deferredTasks的异常情况。

  • T1：Thread A解锁后，Main Thread在-[UIKeyboardTaskQueue performDeferredTaskIfIdle]方法内加锁成功后，在-[UIKeyboardTaskQueue promoteDeferredTaskIfIdle]方法内执行指令bl _objc_msgSend$objectAtIndex:后获取数组inde = 0的对象地址时，因多线程写入导致该对象地址被异常破坏而出现野指针（野指针存入x0寄存器）。

  • T2：Main Thread继续执行下一条指令bl _objc_claimAutoreleasedReturnValue会间接触发了_objc_retain并透传x0寄存器的值，最终在该函数内执行指令ldr x17, [x17, #0x20]时 Crash 了。

注：不同语言的编译器对应的符号名的生成规则是不同的，C 语言只是在原函数名前加一个前缀“_”，如objc_retain(A)，编译后符号名是_objc_retain，而 C++ 语言会根据方法名加上参数名生成的符号名，如__ZNSt3__16vectorIdNS_9allocatorIdEEEixB6v15006Em。

模拟 Crash

按推演的逻辑用本地 Xcode 重新起个 Demo 验证下（可用下文附件中 Demo 关键代码），通过调用[self test_crash]可模拟出 tryLock 失败时导致的 Crash（如调用[self test_ok]就不会出现 Crash），现场如下。

图 11 模拟 tryLock 加锁失败而导致的 Crash

从 Xcode 的 Console 控制台的日志中可以看到出现多线程并发添加到_deferredTasks数组的情况，在后续removeEntry_crash方法内出现了objc_retain野指针对象导致的 Crash，与上述推演的逻辑相符。

对比不同 iOS 版本

图 12 对比不同 iOS 版本的实现

通过对比发现仅 iOS 16 上有问题，iOS 15 或 iOS 17 上 tryLock 失败后都会立即return的，也就是为什么 Crash 仅出现在 iOS 16 的原因。从中我们可以看出在 iOS 17 上苹果技术同学也发现了该 Bug 并做了修复。

给苹果反馈 Bug

该问题已提交至苹果“反馈助理”（图 13），但截至目前未得到其官方的 iOS 16 上的解决方案。

图 13 “反馈助理”截图


六、总结根因

通过上述分析推演，iOS 16 键盘 Crash 的根因已查明，即-[UIKeyboardTaskQueue continueExecutionOnMainThread]方法内执行-[UIKeyboardTaskQueue tryLockWhenReadyForMainThread]尝试加锁失败后，不return继续向下执行读写不安全内存以及解锁，导致存在锁失效的情况，使得UIKeyboardTaskQueue成员变量_deferredTasks数组在多线程下出现并发添加UIKeyboardTaskEntry实例而引起野指针，导致最终 Crash。

注：该根因除了导致数组读写异常而 Crash，也可能导致其他变量的状态不一致性，只是不一定表现为 Crash 而已，建议用本文方案修复。

解决方案（App 内置补丁源码）

明确根因后，解决方案就比较明确了，写一个 App 内置补丁代码使得-[UIKeyboardTaskQueue continueExecutionOnMainThread]方法内执行-[UIKeyboardTaskQueue tryLockWhenReadyForMainThread]尝试加锁失败后，正常return即可。补丁方案有两个：

  1. 重写-[UIKeyboardTaskQueue continueExecutionOnMainThread]方法。在原汇编基础上新增一条指令，即在bl _objc_msgSend$tryLockWhenReadyForMainThread后添加一条汇编指令cbz w0, return_label（return_label对应源码return对应的汇编指令地址），如失败则return。但该方案涉及的原汇编指令较多，有 95 条汇编指令（见下文附件中 iOS 系统汇编），容易踩坑。

  2. 重写-[UIKeyboardTaskQueue tryLockWhenReadyForMainThread]方法。在该方法内如加锁失败则模拟两次return，回到-[UIKeyboardTaskQueue continueExecutionOnMainThread]的上一个函数栈，改造的汇编指令较少，安全性较好，也确认了除-[UIKeyboardTaskQueue continueExecutionOnMainThread]调用外，无其他方法调用-[UIKeyboardTaskQueue tryLockWhenReadyForMainThread]。

最终，支付宝 App 基于稳定性的考虑，采用第 2 种补丁方案修复键盘 Crash。

补丁原理

图 14 修复键盘 Crash 的补丁原理


在-[UIKeyboardTaskQueue tryLockWhenReadyForMainThread]实现以下逻辑：

  • 如加锁成功，则return 1 次，返回到-[UIKeyboardTaskQueue continueExecutionOnMainThread]方法的下一条指令继续执行；

  • 如加锁失败，则模拟return 2 次，返回到-[UIKeyboardTaskQueue continueExecutionOnMainThread]的函数栈的上一层函数的地址继续执行，也就是模拟了从-[UIKeyboardTaskQueue continueExecutionOnMainThread]中执行return操作。

源码return语句，对应汇编的 4 步：

  1. 恢复fp和lr寄存器。fp（也称x29）记录当前帧的内存地址，lr（也称x30）记录从当前函数返回时跳转到哪个地址继续执行。运行时就是通过fp和lr寄存器，输出线程的函数栈的。如 Crash 函数栈，或从lldb的bt输出的函数栈；

  2. 恢复callee-saved寄存器。即x19-x28的寄存器，try-catch的实现就涉及该类寄存器，一般按需执行；

  3. 恢复sp寄存器。sp记录当前帧的栈顶地址，，当前函数的局部变量所在的内存地址就在(fp, sp]之间；

  4. 执行ret指令。执行ret指令后，pc就指向lr寄存器的值，然后继续执行；

本文补丁方案的原理中，tryLock 失败时就是通过：恢复fp和lr寄存器 + 恢复callee-saved寄存器 + 恢复sp寄存器 + 再次恢复fp和lr寄存器 + 再次恢复callee-saved寄存器 + 再次恢复sp寄存器 + ret指令 来模拟在-[UIKeyboardTaskQueue tryLockWhenReadyForMainThread]方法内return 2 次直接返回到-[UIKeyboardTaskQueue continueExecutionOnMainThread]的函数栈的上一层函数的。

补丁实现

有两部分组成：

  1. 重写方法：对应 fix_UIKeyboardTaskQueue.S 文件；

  2. Hook 入口：对应 fix_UIKeyboardTaskQueue.m 文件；

重写方法

重写-[UIKeyboardTaskQueue tryLockWhenReadyForMainThread]方法实现，对应下文附件中补丁源码的 fix_UIKeyboardTaskQueue.S 文件。

图 15 重写 -[UIKeyboardTaskQueue tryLockWhenReadyForMainThread] 方法实现

Hook 入口

借助+ (void)load方法在 App 启动时执行的特点实现对-[UIKeyboardTaskQueue tryLockWhenReadyForMainThread]方法的 Hook，仅在 iOS 16 的 Arm64 架构上生效，对应下文附件中补丁源码的 fix_UIKeyboardTaskQueue.m 文件。

图 16 Hook 入口的代码

方案效果

于 2023.8.25 在支付宝 App 近期版本 10.5.16.6000 上全量开启解决方案的开关后，该版本上的 Crash 日 PV 已经降到 0 了。

图 17 支付宝 App 近期版本 10.5.16.6000 上键盘 Crash 日 PV

同时，支付宝 App 的全量版本（包括所有历史版本）的键盘 Crash 日 PV 下降了近 90%，随着更多用户升级到支付宝 App 最新版本，预计会降到个位数。

图 18 方案上线后键盘 Crash 日 PV 明显下降的趋势图

最终该方案由验收人确认有效，键盘 Crash 已解决，揭榜挑战成功，附上一张挑战成功捷报图收个尾。

图 19 蚂蚁内部的技术英雄榜捷报

附件

1、补丁源码

补丁源码包括两部分：fix_UIKeyboardTaskQueue.S 和 fix_UIKeyboardTaskQueue.m。使用时将该两文件直接内置在 App 中即可，也可在 App 启动时加开关控制 Hook 入口的时机。

2、Demo 关键源码

3、脚本源码

4、iOS 系统汇编（关键方法）

将 iOS 16.6 的 iPhone 12 Pro Max（Hardware Mode: iPhone13 4）设备连接到 Xcode 后，按如下操作可获取到 UIKeyboardTaskQueue 类的实现汇编，即UIKitCore_20G75_arm64e_TEXT.txt 文件。

  🔗 相关链接

[1] Arm64 寄存器说明：https://developer.arm.com/documentation/den0024/a/The-ABI-for-ARM-64-bit-Architecture/Register-use-in-the-AArch64-Procedure-Call-Standard/Parameters-in-general-purpose-registers

[2] Arm64 汇编指令集说明：https://documentation-service.arm.com/static/6023d5512cb3723f20208db2

[3] NSConditionLock 条件状态锁：https://developer.apple.com/documentation/foundation/nsconditionlock/

标签：

我给 iOS 系统打了个补丁——修复 iOS 16 系统键盘重大 Crash的评论 (共 条)

分享到微博请遵守国家法律