我给 iOS 系统打了个补丁——修复 iOS 16 系统键盘重大 Crash
🙋🏻♀️ 编者按:本文作者是蚂蚁集团客户端工程师巴乐,通过逆向分析发现了 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 日志关键信息如下:
1 | Incident Identifier: 7C53A274-4184-4E38-B27E-07B4E1335277 |
提取 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 寄存器说明、Arm64 汇编指令集说明;
- 脚本工具:
otool
、自研脚本fetch_class_text_from_all.sh
; - 关键类:
UIKeyboardTaskQueue
键盘核心类、NSConditionLock
条件状态锁(具体使用见官方文档); - 依赖模块:蚂蚁自研的
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 设置断点模拟现场
- 为模拟与 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
对象后,对该对象是读操作还是写操作。-[UIKeyboardTaskQueue isEmpty]:
…
0000000189c816a4 ldr x0, [x19, #0x20] 读
0000000189c816a8 bl _objc_msgSend$count
…-[UIKeyboardTaskQueue finishExecution]:
…
00000001894677a8 ldr x0, [x19, #0x20] 读
00000001894677ac bl _objc_msgSend$count
…-[UIKeyboardTaskQueue promoteDeferredTaskIfIdle]:
…
0000000189c8152c ldr x0, [x0, #0x20] 读
0000000189c81530 bl _objc_msgSend$count
0000000189c81534 cbz x0, 0x189c81518
0000000189c81538 ldr x0, [x19, #0x20] 读
0000000189c8153c mov x2, #0x0
0000000189c81540 bl “_objc_msgSend$objectAtIndex:”
0000000189c81544 bl 0x18c9deec0 Crash在这行
…
0000000189c81558 ldr x0, [x19, #0x20] 写:删除item
0000000189c8155c mov x2, #0x0
0000000189c81560 bl “_objc_msgSend$removeObjectAtIndex:”
…-[UIKeyboardTaskQueue continueExecutionOnMainThread]:
…
0000000189467130 ldr x0, [x19, #0x20] 读
0000000189467134 bl _objc_msgSend$count
…-[UIKeyboardTaskQueue waitUntilAllTasksAreFinished]:
…
000000018952a810 ldr x0, [x19, #0x20] 读
000000018952a814 bl _objc_msgSend$count
…-[UIKeyboardTaskQueue addDeferredTask:]:
…
0000000189c81640 ldr x0, [x19, #0x20] 写:添加item
0000000189c81644 ldr x2, [sp, #0x8]
0000000189c81648 bl “_objc_msgSend$addObject:”
…-[UIKeyboardTaskQueue init]:
…
0000000189543024 ldr x8, [x19, #0x20] 读
0000000189543028 str x0, [x19, #0x20] 写:创建数组实例
…-[UIKeyboardTaskQueue .cxx_destruct]:
…
0000000189c817f4 add x0, x19, #0x20 写:销毁
0000000189c817f8 mov x1, #0x0
0000000189c817fc bl 0x18a1a4c64 ; symbol stub for: _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 16 键盘 Crash 根因已查明,即-[UIKeyboardTaskQueue continueExecutionOnMainThread]
方法内执行-[UIKeyboardTaskQueue tryLockWhenReadyForMainThread]
尝试加锁失败后,不return
继续向下执行读写不安全内存以及解锁,导致存在锁失效的情况,使得UIKeyboardTaskQueue
成员变量_deferredTasks
数组在多线程下出现并发添加UIKeyboardTaskEntry
实例而引起野指针,导致最终 Crash。
注:该根因除了导致数组读写异常而 Crash,也可能导致其他变量的状态不一致性,只是不一定表现为 Crash 而已,建议用本文方案修复。
解决方案(App 内置补丁源码)
明确根因后,解决方案就比较明确了,写一个 App 内置补丁代码使得-[UIKeyboardTaskQueue continueExecutionOnMainThread]
方法内执行-[UIKeyboardTaskQueue tryLockWhenReadyForMainThread]
尝试加锁失败后,正常return
即可。 补丁方案有两个:
- 重写
-[UIKeyboardTaskQueue continueExecutionOnMainThread]
方法。在原汇编基础上新增一条指令,即在bl _objc_msgSend$tryLockWhenReadyForMainThread
后添加一条汇编指令cbz w0, return_label
(return_label
对应源码return
对应的汇编指令地址),如失败则return
。但该方案涉及的原汇编指令较多,有 95 条汇编指令(见下文附件中 iOS 系统汇编),容易踩坑。 - 重写
-[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 步:
- 恢复
fp
和lr
寄存器。fp
(也称x29
)记录当前帧的内存地址,lr
(也称x30
)记录从当前函数返回时跳转到哪个地址继续执行。运行时就是通过fp
和lr
寄存器,输出线程的函数栈的。如 Crash 函数栈,或从lldb
的bt
输出的函数栈; - 恢复
callee-saved
寄存器。即x19-x28
的寄存器,try-catch
的实现就涉及该类寄存器,一般按需执行; - 恢复
sp
寄存器。sp
记录当前帧的栈顶地址,,当前函数的局部变量所在的内存地址就在(fp
,sp
]之间; - 执行
ret
指令。执行ret
指令后,pc
就指向lr
寄存器的值,然后继续执行;
本文补丁方案的原理中,tryLock 失败时就是通过:恢复fp
和lr
寄存器 + 恢复callee-saved
寄存器 + 恢复sp
寄存器 + 再次恢复fp
和lr
寄存器 + 再次恢复callee-saved
寄存器 + 再次恢复sp
寄存器 + ret
指令 来模拟在-[UIKeyboardTaskQueue tryLockWhenReadyForMainThread]
方法内return
2 次直接返回到-[UIKeyboardTaskQueue continueExecutionOnMainThread]
的函数栈的上一层函数的。
补丁实现
有两部分组成:
- 重写方法:对应 fix_UIKeyboardTaskQueue.S 文件;
- 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 入口的时机。
1 | #ifdef __arm64__ |
2、Demo 关键源码
1 | // |
4、iOS 系统汇编(关键方法)
将 iOS 16.6 的 iPhone 12 Pro Max(Hardware Mode: iPhone13 4)设备连接到 Xcode 后,按如下操作可获取到 UIKeyboardTaskQueue 类的实现汇编,即UIKitCore_20G75_arm64e_TEXT.txt 文件。
1 | otool -s __TEXT __text -v ~/Library/Developer/Xcode/iOS\ DeviceSupport/16.6\ \(20G75\)\ arm64e/Symbols/System/Library/PrivateFrameworks/UIKitCore.framework/UIKitCore > ~/Desktop/UIKitCore_20G75_arm64e_TEXT.txt |
1 | -[UIKeyboardTaskQueue continueExecutionOnMainThread]: |