🙋🏻♀️ 编者按：本文作者是蚂蚁集团客户端工程师巴乐，通过逆向分析发现了 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 日志关键信息如下：
IncidentIdentifier: 7C53A274-4184-4E38-B27E-07B4E1335277CrashReporterKey: HardwareModel: iPhone134Process: AlipayWallet [89329] Path: /private/var/containers/Bundle/Application/C5F00AEC-B96F-4BF1-8C9C-25B67BCA301E/AlipayWallet.app/AlipayWalletIdentifier: com.alipay.iphoneclientVersion: 10.5.0 (10.5.0.6000) CodeType: ARM-64ParentProcess: [1] Date/Time: 2023-08-3004:37:48+0000OSVersion: iPhoneOS16.6 (20G75) ReportVersion: 104ExceptionType: SIGSEGVExceptionCodes: SEGV_MAPERRat0x2ab3106e0CrashedThread: 0Thread0Crashed: 0libobjc.A.dylib0x00000001a5183a7c_objc_retain :16 (inlibobjc.A.dylib) 1UIKitCore0x00000001aed4d4d4-[UIKeyboardTaskQueueperformDeferredTaskIfIdle] :32 (inUIKitCore) 2UIKitCore0x00000001ae533148-[UIKeyboardTaskQueuecontinueExecutionOnMainThread] :376 (inUIKitCore) 3Foundation0x00000001a63e878c___NSThreadPerformPerform :264 (inFoundation) 4CoreFoundation0x00000001ac1ca128___CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ :28 (inCoreFoundation) 5CoreFoundation0x00000001ac1d67b4___CFRunLoopDoSource0 :176 (inCoreFoundation) 6CoreFoundation0x00000001ac15b648___CFRunLoopDoSources0 :340 (inCoreFoundation) 7CoreFoundation0x00000001ac1710d4___CFRunLoopRun :828 (inCoreFoundation) 8CoreFoundation0x00000001ac1763ec_CFRunLoopRunSpecific :612 (inCoreFoundation) 9GraphicsServices0x00000001e768c35c_GSEventRunModal :164 (inGraphicsServices) 10UIKitCore0x00000001ae502f58-[UIApplication_run] :888 (inUIKitCore) 11UIKitCore0x00000001ae502bbc_UIApplicationMain :340 (inUIKitCore) 12AlipayWallet0x00000001074d539cmainmain.m:124 (inAlipayWallet) 13???0x00000001cb6a8dec0x0000000000000000+0Thread1: 0libsystem_kernel.dylib0x00000001eb0b6ca4_mach_msg2_trap :8 (inlibsystem_kernel.dylib) ... ThreadState: x8:0x0000000202aa4820x9:0x0000000282d64100lr:0x00000001aed4d548fp:0x000000016b032700x10:0x0000000000000000x12:0x0000000000ec0e80x11:0x000000000000001fx14:0x0100000202aaecc9x13:0x0000010000000100x16:0x0000bb12ab3106c0sp:0x000000016b0326e0x15:0x0000000202aaecc8x18:0x0000000000000000x17:0x00000002ab3106c0x19:0x0000000283463d00cpsr:0x0000000000001000pc:0x00000001a5183a7cx21:0x0000000000000001x20:0x0000000000000000x0:0x0000000286f706c0x23:0x0000000114841058x1:0x0000000000000000x22:0x000000028312e2c0x2:0x0000000000000000x25:0x0000000000000002x3:0x00000002041bc480x24:0x0000000000000000x4:0x0000000000000000x27:0x00000000211200d5x5:0x0000000000000001x26:0x0000000000000000x6:0x00000001b55fb2c5x7:0x00000001b55fb2b9x28:0x0000000000000001BinaryImages: 0x0000000104dcc000-0x000000010f6f3fffAlipayWalletarm64<fa235f8a8e253b4d81e7e6a4fecdd4c6>/private/var/containers/Bundle/Application/C5F00AEC-B96F-4BF1-8C9C-25B67BCA301E/AlipayWallet.app/AlipayWallet... 0x00000001a5180000-0x00000001a51c3f9flibobjc.A.dylibarm64e<eb7faf215c9f37848907affa6d92bc3b>/usr/lib/libobjc.A.dylib... 0x00000001ae166000-0x00000001af98afffUIKitCorearm64e<7d57a1d1856f338d97db880c4ec8b02e>/System/Library/PrivateFrameworks/UIKitCore.framework/UIKitCore...
提取 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 系统键盘控件的内存管理异常导致。
分析推演
下文分析推演涉及的知识点或技能：
- 使用软件：Sublime Text、Xcode 及自带的
lldb命令，包括b、c、bt、frame select、di、image list、p/x、po、x/1b； - 汇编能力：Arm64 寄存器说明 [1] 、Arm64 汇编指令集说明 [2] ;
- 脚本工具：
otool、自研脚本fetch_class_text_from_all.sh； - 关键类：
UIKeyboardTaskQueue键盘核心类、NSConditionLock条件状态锁（具体使用见官方文档 [3] ）； - 依赖模块：蚂蚁自研的
DebugKit.framework（后续考虑对外输出）调试模块。
一、看现场，从 Crash 点开始
——计算 Crash 函数的偏移
因 iOS 运行时加载到内存的 Image 的起始地址是动态的（对应 Binary Images 列表中的起始地址），但某指令地址与所属 Image 的起始地址的偏移是固定的，所以可根据该偏移来查看 Crash 时是哪条指令。
0x00000001a5183a7c _objc_retain所属的libobjc.A.dylib的起始地址是0x00000001a5180000，所以相对偏移 =0x00000001a5183a7c-0x00000001a5180000=0x3a7c0x00000001aed4d4d4 -[UIKeyboardTaskQueue performDeferredTaskIfIdle]所属的UIKitCore的起始地址是0x00000001ae166000，所以相对偏移 =0x00000001aed4d4d4-0x00000001ae166000=0xbe74d4
二、模拟现场，寻找蛛丝马迹
—— Xcode 设置断点模拟现场
- 为模拟与 Crash 时一样的现场，需找一台与 Crash 日志中一致的设备，即 iOS 16.6 的iPhone 12 Pro Max（Hardware Mode: iPhone13 4），只有这样在下文中断点时的函数栈以及各函数偏移对应的指令才能与 Crash 日志中的完全对上。
- 将找到的设备与 Mac 连接并用 Xcode 启动 App（可用下文附件中 Demo 关键代码调试）。
- 从上述计算出的关键函数的偏移加上所属 Image 的起始地址，模拟出 Crash 时运行的函数栈，具体操作如下图 4。
图 4 设置断点模拟现场
从图 4 的第 11 步可知 Crash 的直接原因是objc_retain的对象野指针了，导致读取内存异常而触发 Crash。
图 5 查看上一层函数栈
从图 5 可知两点：
- 先后调用关系是
-[UIKeyboardTaskQueue performDeferredTaskIfIdle]->-[UIKeyboardTaskQueue promoteDeferredTaskIfIdle]（该函数在 Crash 函数栈中未出现，所以只有模拟现场才能发现）->objc_retain 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 可知两点：
UIKeyboardTaskQueue的成员变量_deferredTasks的类型是NSMutableArray（在实例对象起始地址偏移0x20的位置，从图 6 中第 6 点可知）就是上述提到关键数组。野指针一般是有多线程读写对象导致的，对_deferredTasks数组读写时应该是有锁来控制的，该类中类型为NSConditionLock的成员变量_lock（在实例对象偏移0x10的位置，从图 6 中第 5 点可知）与_deferredTasks是啥关系？- 发现该类的
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关系
理清以下重要的两个关系：
_deferredTasks角度：UIKeyboardTaskQueue类对_deferredTasks的多线程读写是如何保证安全的，哪些方法有用到，与_lock又是什么关系？_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对象后，对该对象是读操作还是写操作。
-[UIKeyboardTaskQueueisEmpty]: ... 0000000189c816a4ldrx0, [x19, #0x20] 读0000000189c816a8bl_objc_msgSend$count... -[UIKeyboardTaskQueuefinishExecution]: ... 00000001894677a8ldrx0, [x19, #0x20] 读00000001894677acbl_objc_msgSend$count... -[UIKeyboardTaskQueuepromoteDeferredTaskIfIdle]: ... 0000000189c8152cldrx0, [x0, #0x20] 读0000000189c81530bl_objc_msgSend$count0000000189c81534cbzx0, 0x189c815180000000189c81538ldrx0, [x19, #0x20] 读0000000189c8153cmovx2, #0x00000000189c81540bl"_objc_msgSend$objectAtIndex:"0000000189c81544bl0x18c9deec0Crash在这行... 0000000189c81558ldrx0, [x19, #0x20] 写：删除item0000000189c8155cmovx2, #0x00000000189c81560bl"_objc_msgSend$removeObjectAtIndex:"... -[UIKeyboardTaskQueuecontinueExecutionOnMainThread]: ... 0000000189467130ldrx0, [x19, #0x20] 读0000000189467134bl_objc_msgSend$count... -[UIKeyboardTaskQueuewaitUntilAllTasksAreFinished]: ... 000000018952a810ldrx0, [x19, #0x20] 读000000018952a814bl_objc_msgSend$count... -[UIKeyboardTaskQueueaddDeferredTask:]: ... 0000000189c81640ldrx0, [x19, #0x20] 写：添加item0000000189c81644ldrx2, [sp, #0x8] 0000000189c81648bl"_objc_msgSend$addObject:"... -[UIKeyboardTaskQueueinit]: ... 0000000189543024ldrx8, [x19, #0x20] 读0000000189543028strx0, [x19, #0x20] 写：创建数组实例... -[UIKeyboardTaskQueue .cxx_destruct]: ... 0000000189c817f4addx0, x19, #0x20写：销毁0000000189c817f8movx1, #0x00000000189c817fcbl0x18a1a4c64 ; symbolstubfor: _objc_storeStrong...
读_deferredTasks的方法有 6 个：
-[UIKeyboardTaskQueue isEmpty]-[UIKeyboardTaskQueue finishExecution]-[UIKeyboardTaskQueue promoteDeferredTaskIfIdle]-[UIKeyboardTaskQueue continueExecutionOnMainThread]-[UIKeyboardTaskQueue waitUntilAllTasksAreFinished]-[UIKeyboardTaskQueue init]
写_deferredTasks的方法有 4 个：
-[UIKeyboardTaskQueue promoteDeferredTaskIfIdle]-[UIKeyboardTaskQueue addDeferredTask:]-[UIKeyboardTaskQueue init]-[UIKeyboardTaskQueue .cxx_destruct]
_lock 角度
在文件中全文搜索正则表达式x.{1,2}, #0x10筛选出所有引用_lock的指令以及所属方法，操作类似上述的_deferredTasks；从上可知，UIKeyboardTaskQueue类对_lock的使用封装成 4 个方法（忽略init创建和.cxx_destruct销毁的两个方法，该两方法不会有并发问题），也就是方法使用_lock必定会调用这 4 个方法。
解锁方法有 1 个：
-[UIKeyboardTaskQueue unlock]
加锁方法有 3 个：
-[UIKeyboardTaskQueue lock]-[UIKeyboardTaskQueue lockWhenReadyForMainThread]-[UIKeyboardTaskQueue tryLockWhenReadyForMainThread]
串联关系，发现 Bug
串联上述_deferredTasks和_lock两个角度的方法调用（忽略init创建和.cxx_destruct销毁的两个方法），从原汇编的关键方法中列出简版的关系描述，如下图 9。
图 9 串联 _deferredTasks 和 _lock 的关系
为方便理清锁的对应关系，图 9 中用红色表示加锁，绿色表示解锁，从中可知：
- 对
_deferredTasks的关键读写的方法内是有 1 个加锁和 1 个解锁对应的，预期是多线程下保护读写的安全性； - 即使不读写
_deferredTasks的方法内上也是有 1 个加锁和 1 个解锁对应的，用于多线程下保护其他成员变量的读写安全性； - 发现问题，有 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 系统打了个补丁——修复 iOS 16 系统键盘重大 Crash(下）
