本文来源:支付宝体验科技
🙋🏻♀️ 编者按:本文作者是蚂蚁集团客户端工程师巴乐,通过逆向分析发现了 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 日志关键信息如下:
Incident Identifier: 7C53A274-4184-4E38-B27E-07B4E1335277 CrashReporter Key: Hardware Model: iPhone13 4 Process: AlipayWallet [89329] Path: /private/var/containers/Bundle/Application/C5F00AEC-B96F-4BF1-8C9C-25B67BCA301E/AlipayWallet.app/AlipayWallet Identifier: com.alipay.iphoneclient Version: 10.5.0 (10.5.0.6000) Code Type: ARM-64 Parent Process: [1] Date/Time: 2023-08-30 04:37:48 +0000 OS Version: iPhone OS 16.6 (20G75) Report Version: 104 Exception Type: SIGSEGV Exception Codes: SEGV_MAPERR at 0x2ab3106e0 Crashed Thread: 0 Thread 0 Crashed: 0 libobjc.A.dylib 0x00000001a5183a7c _objc_retain :16 (in libobjc.A.dylib) 1 UIKitCore 0x00000001aed4d4d4 -[UIKeyboardTaskQueue performDeferredTaskIfIdle] :32 (in UIKitCore) 2 UIKitCore 0x00000001ae533148 -[UIKeyboardTaskQueue continueExecutionOnMainThread] :376 (in UIKitCore) 3 Foundation 0x00000001a63e878c ___NSThreadPerformPerform :264 (in Foundation) 4 CoreFoundation 0x00000001ac1ca128 ___CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ :28 (in CoreFoundation) 5 CoreFoundation 0x00000001ac1d67b4 ___CFRunLoopDoSource0 :176 (in CoreFoundation) 6 CoreFoundation 0x00000001ac15b648 ___CFRunLoopDoSources0 :340 (in CoreFoundation) 7 CoreFoundation 0x00000001ac1710d4 ___CFRunLoopRun :828 (in CoreFoundation) 8 CoreFoundation 0x00000001ac1763ec _CFRunLoopRunSpecific :612 (in CoreFoundation) 9 GraphicsServices 0x00000001e768c35c _GSEventRunModal :164 (in GraphicsServices) 10 UIKitCore 0x00000001ae502f58 -[UIApplication _run] :888 (in UIKitCore) 11 UIKitCore 0x00000001ae502bbc _UIApplicationMain :340 (in UIKitCore) 12 AlipayWallet 0x00000001074d539c main main.m:124 (in AlipayWallet) 13 ??? 0x00000001cb6a8dec 0x0000000000000000 + 0 Thread 1: 0 libsystem_kernel.dylib 0x00000001eb0b6ca4 _mach_msg2_trap :8 (in libsystem_kernel.dylib) ... Thread State: x8:0x0000000202aa4820 x9:0x0000000282d64100 lr:0x00000001aed4d548 fp:0x000000016b032700 x10:0x0000000000000000 x12:0x0000000000ec0e80 x11:0x000000000000001f x14:0x0100000202aaecc9 x13:0x0000010000000100 x16:0x0000bb12ab3106c0 sp:0x000000016b0326e0 x15:0x0000000202aaecc8 x18:0x0000000000000000 x17:0x00000002ab3106c0 x19:0x0000000283463d00 cpsr:0x0000000000001000 pc:0x00000001a5183a7c x21:0x0000000000000001 x20:0x0000000000000000 x0:0x0000000286f706c0 x23:0x0000000114841058 x1:0x0000000000000000 x22:0x000000028312e2c0 x2:0x0000000000000000 x25:0x0000000000000002 x3:0x00000002041bc480 x24:0x0000000000000000 x4:0x0000000000000000 x27:0x00000000211200d5 x5:0x0000000000000001 x26:0x0000000000000000 x6:0x00000001b55fb2c5 x7:0x00000001b55fb2b9 x28:0x0000000000000001 Binary Images: 0x0000000104dcc000 - 0x000000010f6f3fff AlipayWallet arm64 <fa235f8a8e253b4d81e7e6a4fecdd4c6> /private/var/containers/Bundle/Application/C5F00AEC-B96F-4BF1-8C9C-25B67BCA301E/AlipayWallet.app/AlipayWallet ... 0x00000001a5180000 - 0x00000001a51c3f9f libobjc.A.dylib arm64e <eb7faf215c9f37848907affa6d92bc3b> /usr/lib/libobjc.A.dylib ... 0x00000001ae166000 - 0x00000001af98afff UIKitCore arm64e <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
=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 已解决,揭榜挑战成功,附上一张挑战成功捷报图收个尾。
附件
1、补丁源码
补丁源码包括两部分:fix_UIKeyboardTaskQueue.S 和 fix_UIKeyboardTaskQueue.m。使用时将该两文件直接内置在 App 中即可,也可在 App 启动时加开关控制 Hook 入口的时机。
#ifdef __arm64__ // // fix_UIKeyboardTaskQueue.S // fix_UIKeyboardTaskQueue // // Created by Alipay on 2023/8/10. // Copyright © 2023 Alipay. All rights reserved. // /** 原实现 -[UIKeyboardTaskQueue tryLockWhenReadyForMainThread]: ldr x0, [x0, #0x10] mov x2, #0x0 b "_objc_msgSend$tryLockWhenCondition:" */ // 重写实现 .section __TEXT,__cstring,cstring_literals tryLockWhenCondition.str: .asciz "tryLockWhenCondition:" .text .align 4 .global _fix_UIKeyboardTaskQueue_tryLockWhenReadyForMainThread .cfi_startproc _fix_UIKeyboardTaskQueue_tryLockWhenReadyForMainThread: stp x20, x19, [sp, #-0x20]! stp x29, x30, [sp, #0x10] add x29, sp, #0x10 mov x19, x0 ; self adrp x0, tryLockWhenCondition.str@PAGE add x0, x0, tryLockWhenCondition.str@PAGEOFF bl _sel_registerName ; @selector(tryLockWhenCondition:) mov x1, x0 ldr x0, [x19, #0x10] ; _lock mov x2, #0x0 bl _objc_msgSend ; -[_lock tryLockWhenCondition:0] ldp x29, x30, [sp, #0x10] ; 恢复fp和lr ldp x20, x19, [sp], #0x20 ; 恢复callee-saved寄存器、并恢复sp cbz x0, 1f // 如tryLock成功,则继续执行-[UIKeyboardTaskQueue continueExecutionOnMainThread]的指令 ret // 如tryLock失败,则模拟从-[UIKeyboardTaskQueue continueExecutionOnMainThread] return,不再继续执行 1: ldp x29, x30, [sp, #0x20] ; 恢复fp和lr ldp x20, x19, [sp, #0x10] ; 恢复callee-saved寄存器 add sp, sp, #0x30 ; 恢复sp autibsp ; Authenticate Instruction address ret .cfi_endproc #endif
// // fix_UIKeyboardTaskQueue.m // fix_UIKeyboardTaskQueue // // Created by Alipay on 2023/9/4. // #ifdef __arm64__ #import <UIKit/UIKit.h> #include <objc/runtime.h> @interface fix_UIKeyboardTaskQueue : NSObject @end @implementation fix_UIKeyboardTaskQueue + (void)load { extern BOOL fix_UIKeyboardTaskQueue_tryLockWhenReadyForMainThread(id self, SEL selector); if (@available(iOS 16.0, *)) { NSString *systemVersion = [[UIDevice currentDevice] systemVersion]; NSArray *verInfos = [systemVersion componentsSeparatedByString:@"."]; NSUInteger count = [verInfos count]; if (count >= 2) { if ([verInfos[0] isEqualToString:@"16"]) { class_replaceMethod(objc_getClass("UIKeyboardTaskQueue"), sel_getUid("tryLockWhenReadyForMainThread"), (IMP)fix_UIKeyboardTaskQueue_tryLockWhenReadyForMainThread, "B16@0:8"); } } } } @end #endif
2、Demo 关键源码
// // ViewController.m // UIKeyboardTaskQueueDemo // // Created by Alipay on 2023/8/30. // #import "ViewController.h" #include <objc/runtime.h> // #import <DebugKit/DebugKit.h> @interface ViewController () @end @implementation ViewController { NSMutableArray *_tasks; NSMutableArray *_deferredTasks; NSConditionLock *_lock; } - (void)viewDidLoad { [super viewDidLoad]; // 输出UIKeyboardTaskQueue的所有实例方法和类方法 // dk_print_all_methods_of_class("UIKeyboardTaskQueue"); // 输出UIKeyboardTaskQueue的所有property // dk_print_all_properties("UIKeyboardTaskQueue"); // 输出UIKeyboardTaskQueue的所有ivars // dk_print_class_all_ivars("UIKeyboardTaskQueue"); UITextView *textView = [[UITextView alloc] initWithFrame:self.view.bounds]; [self.view addSubview:textView]; [self test_crash]; [self test_ok]; } - (void)unlock { [_lock unlockWithCondition:0]; } - (void)lock { [_lock lock]; } - (BOOL)tryLock { return [_lock tryLockWhenCondition:0]; } - (void)addEntry_ok { [self lock]; [_deferredTasks addObject:[[NSObject alloc] init]]; NSLog(@"add, %lu", _deferredTasks.count); [self unlock]; } - (void)removeEntry_crash { [self tryLock]; if (_deferredTasks.count) { [_tasks addObject:[_deferredTasks objectAtIndex:0]]; if (_deferredTasks.count) { [_deferredTasks removeObjectAtIndex:0]; NSLog(@"remove, %lu", _deferredTasks.count); // NSLog(@"%@, %lu -[_deferredTasks removeObjectAtIndex:0]", [NSThread currentThread], _deferredTasks.count); } } [self unlock]; } - (void)removeEntry_ok { if (![self tryLock]) return; if (_deferredTasks.count) { [_tasks addObject:[_deferredTasks objectAtIndex:0]]; if (_deferredTasks.count) { [_deferredTasks removeObjectAtIndex:0]; NSLog(@"remove, %lu", _deferredTasks.count); // NSLog(@"%@, %lu -[_deferredTasks removeObjectAtIndex:0]", [NSThread currentThread], _deferredTasks.count); } } [self unlock]; } - (void)test_crash { // init _tasks = [NSMutableArray array]; _deferredTasks = [NSMutableArray array]; _lock = [[NSConditionLock alloc] initWithCondition:0]; for (int i = 0; i < 10000; i++) { dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{ [self addEntry_ok]; }); dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{ // dispatch_async(dispatch_get_main_queue(), ^{ [self removeEntry_crash]; // }); }); } } - (void)test_ok { // init _tasks = [NSMutableArray array]; _deferredTasks = [NSMutableArray array]; _lock = [[NSConditionLock alloc] initWithCondition:0]; for (int i = 0; i < 1000; i++) { dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{ [self addEntry_ok]; }); dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{ [self removeEntry_ok]; }); } } @end
3、脚本源码
#!/bin/sh # File TEXT_FILE="$1"; # Class CLASS_NAME="$2"; cat "$TEXT_FILE" | tr '\n' '&' | sed 's/&\-\[/\n\-\[/g'|grep "^\-\[$CLASS_NAME " | tr '&' '\n';
4、iOS 系统汇编(关键方法)
将 iOS 16.6 的 iPhone 12 Pro Max(Hardware Mode: iPhone13 4)设备连接到 Xcode 后,按如下操作可获取到 UIKeyboardTaskQueue 类的实现汇编,即UIKitCore_20G75_arm64e_TEXT.txt 文件。
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 ./fetch_class_text_from_all.sh ~/Desktop/UIKitCore_20G75_arm64e_TEXT.txt UIKeyboardTaskQueue > ~/Desktop/UIKeyboardTaskQueue_20G75_arm64e_TEXT.txt
-[UIKeyboardTaskQueue continueExecutionOnMainThread]: 0000000189466fd0 pacibsp 0000000189466fd4 sub sp, sp, #0x30 0000000189466fd8 stp x20, x19, [sp, #0x10] 0000000189466fdc stp x29, x30, [sp, #0x20] 0000000189466fe0 add x29, sp, #0x20 0000000189466fe4 mov x19, x0 0000000189466fe8 bl 0x18c9df5e0 0000000189466fec cmp w0, #0x1 0000000189466ff0 b.ne 0x189467024 0000000189466ff4 mov x0, x19 0000000189466ff8 bl _objc_msgSend$tryLockWhenReadyForMainThread 0000000189466ffc ldr x8, [x19, #0x28] 0000000189467000 cbz x8, 0x189467058 0000000189467004 ldr x8, [x19, #0x30] 0000000189467008 cbz x8, 0x1894670b4 000000018946700c bl 0x18c9df2f0 0000000189467010 str x0, [sp, #0x8] 0000000189467014 ldr x8, [x19, #0x30] 0000000189467018 str xzr, [x19, #0x30] 000000018946701c bl 0x18c9df150 0000000189467020 b 0x1894670ac 0000000189467024 adrp x8, -26465 ; 0x182d06000 0000000189467028 add x2, x8, #0xe19 000000018946702c mov x0, x19 0000000189467030 mov x3, #0x0 0000000189467034 mov w4, #0x0 0000000189467038 ldp x29, x30, [sp, #0x20] 000000018946703c ldp x20, x19, [sp, #0x10] 0000000189467040 add sp, sp, #0x30 0000000189467044 autibsp 0000000189467048 eor x16, x30, x30, lsl #1 000000018946704c tbz x16, #0x3e, 0x189467054 0000000189467050 brk #0xc471 0000000189467054 b "_objc_msgSend$performSelectorOnMainThread:withObject:waitUntilDone:" 0000000189467058 ldr x0, [x19, #0x18] 000000018946705c bl _objc_msgSend$count 0000000189467060 cbz x0, 0x1894670b8 0000000189467064 adrp x8, 333019 ; 0x1da942000 0000000189467068 ldr x0, [x8, #0x500] 000000018946706c bl 0x18c9dee30 0000000189467070 mov x2, x19 0000000189467074 bl "_objc_msgSend$initWithExecutionQueue:" 0000000189467078 mov x20, x0 000000018946707c mov x0, x19 0000000189467080 mov x2, x20 0000000189467084 bl "_objc_msgSend$setExecutionContext:" 0000000189467088 bl 0x18c9df0a0 000000018946708c ldr x0, [x19, #0x18] 0000000189467090 mov x2, #0x0 0000000189467094 bl "_objc_msgSend$objectAtIndex:" 0000000189467098 bl 0x18c9deec0 000000018946709c str x0, [sp, #0x8] 00000001894670a0 ldr x0, [x19, #0x18] 00000001894670a4 mov x2, #0x0 00000001894670a8 bl "_objc_msgSend$removeObjectAtIndex:" 00000001894670ac ldr x0, [sp, #0x8] 00000001894670b0 b 0x1894670b8 00000001894670b4 mov x0, #0x0 00000001894670b8 str x0, [sp, #0x8] 00000001894670bc bl _objc_msgSend$originatingStack 00000001894670c0 bl 0x18c9deec0 00000001894670c4 mov x20, x0 00000001894670c8 mov x0, x19 00000001894670cc mov x2, x20 00000001894670d0 bl "_objc_msgSend$setActiveOriginator:" 00000001894670d4 bl 0x18c9df0a0 00000001894670d8 mov x0, x19 00000001894670dc bl _objc_msgSend$unlock 00000001894670e0 ldr x1, [sp, #0x8] 00000001894670e4 ldrb w20, [x19, #0x8] 00000001894670e8 mov w8, #0x1 00000001894670ec strb w8, [x19, #0x8] 00000001894670f0 ldr x2, [x19, #0x28] 00000001894670f4 cbz x1, 0x189467108 00000001894670f8 mov x0, x1 00000001894670fc bl "_objc_msgSend$execute:" 0000000189467100 ldr x1, [sp, #0x8] 0000000189467104 b 0x18946710c 0000000189467108 cbz x2, 0x189467130 000000018946710c strb w20, [x19, #0x8] 0000000189467110 ldp x29, x30, [sp, #0x20] 0000000189467114 ldp x20, x19, [sp, #0x10] 0000000189467118 add sp, sp, #0x30 000000018946711c autibsp 0000000189467120 eor x16, x30, x30, lsl #1 0000000189467124 tbz x16, #0x3e, 0x18946712c 0000000189467128 brk #0xc471 000000018946712c b 0x18c9df060 0000000189467130 ldr x0, [x19, #0x20] 0000000189467134 bl _objc_msgSend$count 0000000189467138 ldr x1, [sp, #0x8] 000000018946713c cbz x0, 0x18946710c 0000000189467140 mov x0, x19 0000000189467144 bl _objc_msgSend$performDeferredTaskIfIdle 0000000189467148 b 0x189467100 -[UIKeyboardTaskQueue tryLockWhenReadyForMainThread]: 0000000189467738 ldr x0, [x0, #0x10] 000000018946773c mov x2, #0x0 0000000189467740 b "_objc_msgSend$tryLockWhenCondition:" -[UIKeyboardTaskQueue performDeferredTaskIfIdle]: 0000000189c814b4 pacibsp 0000000189c814b8 stp x20, x19, [sp, #-0x20]! 0000000189c814bc stp x29, x30, [sp, #0x10] 0000000189c814c0 add x29, sp, #0x10 0000000189c814c4 mov x19, x0 0000000189c814c8 bl _objc_msgSend$lock 0000000189c814cc mov x0, x19 0000000189c814d0 bl _objc_msgSend$promoteDeferredTaskIfIdle 0000000189c814d4 mov x0, x19 0000000189c814d8 bl _objc_msgSend$unlock 0000000189c814dc mov x0, x19 0000000189c814e0 ldp x29, x30, [sp, #0x10] 0000000189c814e4 ldp x20, x19, [sp], #0x20 0000000189c814e8 autibsp 0000000189c814ec eor x16, x30, x30, lsl #1 0000000189c814f0 tbz x16, #0x3e, 0x189c814f8 0000000189c814f4 brk #0xc471 0000000189c814f8 b _objc_msgSend$continueExecutionOnMainThread -[UIKeyboardTaskQueue promoteDeferredTaskIfIdle]: 0000000189c814fc pacibsp 0000000189c81500 sub sp, sp, #0x30 0000000189c81504 stp x20, x19, [sp, #0x10] 0000000189c81508 stp x29, x30, [sp, #0x20] 0000000189c8150c add x29, sp, #0x20 0000000189c81510 ldr x8, [x0, #0x28] 0000000189c81514 cbz x8, 0x189c81528 0000000189c81518 ldp x29, x30, [sp, #0x20] 0000000189c8151c ldp x20, x19, [sp, #0x10] 0000000189c81520 add sp, sp, #0x30 0000000189c81524 retab 0000000189c81528 mov x19, x0 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 0000000189c81548 mov x2, x0 0000000189c8154c str x0, [sp, #0x8] 0000000189c81550 ldr x0, [x19, #0x18] 0000000189c81554 bl "_objc_msgSend$addObject:" 0000000189c81558 ldr x0, [x19, #0x20] 0000000189c8155c mov x2, #0x0 0000000189c81560 bl "_objc_msgSend$removeObjectAtIndex:" 0000000189c81564 ldr x0, [sp, #0x8] 0000000189c81568 ldp x29, x30, [sp, #0x20] 0000000189c8156c ldp x20, x19, [sp, #0x10] 0000000189c81570 add sp, sp, #0x30 0000000189c81574 autibsp 0000000189c81578 eor x16, x30, x30, lsl #1 0000000189c8157c tbz x16, #0x3e, 0x189c81584 0000000189c81580 brk #0xc471 0000000189c81584 b 0x18c9df050 -[UIKeyboardTaskQueue addDeferredTask:]: 0000000189c815fc pacibsp 0000000189c81600 sub sp, sp, #0x30 0000000189c81604 stp x20, x19, [sp, #0x10] 0000000189c81608 stp x29, x30, [sp, #0x20] 0000000189c8160c add x29, sp, #0x20 0000000189c81610 mov x19, x0 0000000189c81614 bl 0x18c9df200 0000000189c81618 mov x20, x0 0000000189c8161c mov x0, x19 0000000189c81620 bl _objc_msgSend$lock 0000000189c81624 adrp x8, 330945 ; 0x1da942000 0000000189c81628 ldr x0, [x8, #0x510] 0000000189c8162c bl 0x18c9dee30 0000000189c81630 mov x2, x20 0000000189c81634 bl "_objc_msgSend$initWithTask:" 0000000189c81638 str x0, [sp, #0x8] 0000000189c8163c bl 0x18c9df0a0 0000000189c81640 ldr x0, [x19, #0x20] 0000000189c81644 ldr x2, [sp, #0x8] 0000000189c81648 bl "_objc_msgSend$addObject:" 0000000189c8164c mov x0, x19 0000000189c81650 bl _objc_msgSend$unlock 0000000189c81654 mov x0, x19 0000000189c81658 bl _objc_msgSend$continueExecutionOnMainThread 0000000189c8165c ldr x0, [sp, #0x8] 0000000189c81660 ldp x29, x30, [sp, #0x20] 0000000189c81664 ldp x20, x19, [sp, #0x10] 0000000189c81668 add sp, sp, #0x30 0000000189c8166c autibsp 0000000189c81670 eor x16, x30, x30, lsl #1 0000000189c81674 tbz x16, #0x3e, 0x189c8167c 0000000189c81678 brk #0xc471 0000000189c8167c b 0x18c9df050