libAccessibility通知Crash排查記錄分析
Crash 信息
Last Exception : 0 libobjc.A.dylib 0x00000001bee86f40 _objc_msgSend + 32 1 CoreFoundation 0x00000001a6132834 ___CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 28 2 CoreFoundation 0x00000001a61cefd4 ____CFXRegistrationPost_block_invoke + 52 3 CoreFoundation 0x00000001a61a21d0 __CFXRegistrationPost + 456 4 CoreFoundation 0x00000001a61488ac __CFXNotificationPost + 728 5 Foundation 0x00000001a7917754 -[NSNotificationCenter postNotificationName:object:userInfo:] + 96 6 CoreFoundation 0x00000001a6132834 ___CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 28 7 CoreFoundation 0x00000001a61cefd4 ____CFXRegistrationPost_block_invoke + 52 8 CoreFoundation 0x00000001a61a21d0 __CFXRegistrationPost + 456 9 CoreFoundation 0x00000001a61488ac __CFXNotificationPost + 728 10 CoreFoundation 0x00000001a616fe88 _CFNotificationCenterPostNotificationWithOptions + 136 11 libAccessibility.dylib 0x00000001a9e275f4 __updateCachePreferenceAndRepostNotification + 144 12 libAccessibility.dylib 0x00000001a9e21ea8 ____axsHandlePrefChanged_block_invoke + 132 13 libdispatch.dylib 0x00000001a5e06e6c __dispatch_call_block_and_release + 32 14 libdispatch.dylib 0x00000001a5e08a30 __dispatch_client_callout + 20 15 libdispatch.dylib 0x00000001a5e16f48 __dispatch_main_queue_drain + 928 16 libdispatch.dylib 0x00000001a5e16b98 __dispatch_main_queue_callback_4CF + 44 17 CoreFoundation 0x00000001a6159800 ___CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 18 CoreFoundation 0x00000001a6113704 ___CFRunLoopRun + 2532 19 CoreFoundation 0x00000001a6126bc8 _CFRunLoopRunSpecific + 600 20 GraphicsServices 0x00000001c225a374 _GSEventRunModal + 164 21 UIKitCore 0x00000001a8a96648 -[UIApplication _run] + 1100 22 UIKitCore 0x00000001a8817d90 _UIApplicationMain + 364 23 CustomApp 0x0000000100fe1c64 main (main.mm:0) 24 ??? 0x0000000109285ce4 0x000000010926c000 + 0 ------ Exception Type: SIGSEGV SEGV_ACCERR Exception Codes: fault addr: 0x0080000000000008 Crashed Thread: 0 0x1a9e1e000 - 0x1a9e43fff arm64 <309485b32e2c3803ae988866d303d7fd> libAccessibility.dylib
libAccessibility 在發(fā)送通知時(shí)產(chǎn)生了 Crash。
復(fù)現(xiàn)場(chǎng)景
在某些路徑可以復(fù)現(xiàn) Crash：
這里取出對(duì)象 isa 中的 class 對(duì)象 PAC 驗(yàn)簽后使用，在 _objc_msgSend + 32 尋址時(shí) Crash，是典型的對(duì)象內(nèi)存管理異常問題。
但按對(duì)通知中心的認(rèn)知，會(huì)對(duì) observer 弱引用，post 時(shí)不應(yīng)該出現(xiàn)釋放后引用指針未置 nil 的情況。先順便回溯分析一下調(diào)用棧。
簡(jiǎn)單引用分析
CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER 會(huì)跳轉(zhuǎn)到入?yún)?block 的 invoke 函數(shù)：
Foundation`__66-[NSNotificationCenter _addObserver:selector:name:object:options:]_block_invoke:
0x1a8531d0c <+0>: mov x2, x1
0x1a8531d10 <+4>: ldp x8, x1, [x0, #0x20]
0x1a8531d14 <+8>: mvn x0, x8
0x1a8531d18 <+12>: b 0x1a69cadb8
這個(gè)函數(shù)看起來就很熟悉了，在我們常規(guī)的添加通知接口產(chǎn)生。 block 的 invoke 函數(shù)第一個(gè)參數(shù)是 block 本身，<+4> 處是取出該 block 的兩個(gè)引用對(duì)象，他們分別是：
<UILabel: 0x12abb49c0…> _accessibilityButtonShapesChangedNotification:
后續(xù)就是調(diào)用 objc_msgSend 發(fā)送消息了。 接著看一下 block 對(duì)該 observer 的引用類型，最簡(jiǎn)單的方法就是查看該 block 的 dispose 函數(shù)指令，里面會(huì)對(duì)引用的 strong 對(duì)象 release、weak 對(duì)象 storeWeak，把 block 內(nèi)存消息打印出來：
(lldb) re read x0
x0 = 0x0000000281ae8f90
(lldb) x 0x0000000281ae8f90
0x281ae8f90: 30 91 f9 2e 02 00 00 00 06 00 00 c1 00 00 00 00 0...............
0x281ae8fa0: 34 42 4a a8 01 00 00 00 e0 02 95 ff 01 00 00 00 4BJ.............
flags 記錄了 block 變量的各種信息，處于 block 第二個(gè) 8 字節(jié)0xc1000006，其 24 位為 1 說明在堆上，25 位為 0 說明沒有 dispose/copy 函數(shù)，所以這個(gè) block 對(duì) observer 相當(dāng)于 assign 引用。
有些奇怪，向上分析成本太高，直接開啟 Zombie 試圖去找到這個(gè) Crash 的對(duì)象及其產(chǎn)生時(shí)機(jī)。
尋找 Crash 對(duì)象
開啟 Zombie 后果然輕松復(fù)現(xiàn)：
-[UILabel _accessibilityButtonShapesChangedNotification:]: message sent to deallocated instance 0x12b7fc7d0 (lldb) x 0x12b7fc7d0 0x12b7fc7d0: d3 0b cb 83 02 00 00 00 00 00 00 00 00 00 00 00 ................ 0x12b7fc7e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ (lldb) po (Class)0x0283cb0bd3 _NSZombie_UILabel (lldb) p/t 0x0283cb0bd3 (long) $10 = 0b0000000000000000000000000000001010000011110010110000101111010011
Zombie 機(jī)制大概是在對(duì)象 dealloc 時(shí)把對(duì)象的 isa 類部分指向一個(gè)新的類（比如這里的 _NSZombie_UILabel），后續(xù)再向該對(duì)象發(fā)送消息就會(huì)被攔截下來報(bào)錯(cuò)，所以對(duì)象地址不會(huì)變。
那就 Hook UILabel 的-initWithFrame: / dealloc方法，打印其地址、堆棧、父視圖鏈條等消息，觸發(fā) zombie 時(shí)根據(jù)地址找到對(duì)應(yīng)的信息：
dealloc 時(shí) UILabel:0x13bb30d90, 調(diào)用棧:( 0 CustomApp 0x0000000102879b0c -[UIView(QBCrashFix) qbCrashFix_dealloc] + 136 1 CustomApp 0x0000000103d8a3e0 -[UILabel(Foo) dealloc] + 96 2 libobjc.A.dylib 0x00000001aafdd5d8 B3A78098-C0FB-3DCD-B1AC-0712762510DB + 5592 3 libobjc.A.dylib 0x00000001aafe0f40 objc_autoreleasePoolPop + 256 4 CoreFoundation 0x00000001b1ca6a74 _CFAutoreleasePoolPop + 32 5 CoreFoundation 0x00000001b1cb93f8 42C5C917-0447-3995-B50F-DE4D132C2435 + 594936
發(fā)現(xiàn)了罪魁禍?zhǔn)祝?/p>
@implementation UILabel (Foo)
…
- (void)dealloc {
objc_setAssociatedObject(…);
#if !__has_feature(objc_arc)
[super dealloc];
#endif
}
@end
這是在分類里面的定義，相當(dāng)于把-[UILabel dealloc]方法調(diào)用跳過了，看下其實(shí)現(xiàn)：
UIKitCore`-[UILabel dealloc]:
…
0x1b3ed0624 <+52>: bl 0x1b54ad680 ; objc_msgSend$defaultCenter
0x1b3ed0628 <+56>: bl 0x1b75b7840
0x1b3ed062c <+60>: mov x20, x0
0x1b3ed0630 <+64>: ldr x2, [x19, x21]
0x1b3ed0634 <+68>: bl 0x1b544b400 ; objc_msgSend$_removeObserver:
…
發(fā)現(xiàn)內(nèi)部有移除 Notification 的邏輯，由于跳過了這些指令導(dǎo)致通知中心該 observer 未被移除引發(fā) Crash。
這個(gè)文件是直接 copy 的開源代碼，導(dǎo)致了全局-[UILabel dealloc]走不到，再次證明了無腦 copy 代碼的危害性。
另外，比較好奇的點(diǎn)是該場(chǎng)景通知中心對(duì) UILabel 的引用似乎不是弱引用。
通知中心是否一定弱引用 observer
直接 Debug 發(fā)現(xiàn)在 -[UILabel initWithFrame:] 中會(huì)直接調(diào)用到底層接口注冊(cè) Notification：
在 CFXNotificationRegistrarAdd 時(shí)參數(shù)情況是：
(lldb) po $x0 <CFXNotificationRegistrar 0x11aa05cf0 [0x2091ba3a0]> (lldb) po $x1 UIAccessibilityButtonShapesEnabledStatusDidChangeNotification (lldb) po $x3 <UILabel: 0x146f56920…>
確實(shí)和 Crash 時(shí)的通知一致。
斷點(diǎn)到 -[UILabel initWithFrame:] 結(jié)束時(shí)去看一下該對(duì)象的 isa 情況：
(lldb) x 0x146f56920 0x146f56920: bb 90 e7 07 02 00 00 01 00 00 00 00 00 00 00 00 ................ 0x146f56930: 00 00 00 00 00 00 00 00 30 0a 08 3f 01 00 00 00 ........0..?.... (lldb) p/t 0x0100000207e790bb (long) $4 = 0b0000000100000000000000000000001000000111111001111001000010111011
發(fā)現(xiàn) isa 第三個(gè)位也就是 weakly_referenced 的值為0，說明底層注冊(cè) Notification 接口并不會(huì)像 -[NSNotificationCenter addObserver:selector:name:object:] 一樣對(duì) observer 弱引用，所以需要在 dealloc 手動(dòng)移除通知。
以上就是libAccessibility通知Crash排查記錄分析的詳細(xì)內(nèi)容，更多關(guān)于libAccessibility通知Crash排查的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
匯編實(shí)現(xiàn)簡(jiǎn)單選擇排序的方法示例
這篇文章主要介紹了匯編實(shí)現(xiàn)簡(jiǎn)單選擇排序的方法示例，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2020-02-02
匯編程序輸出“Hello world”的實(shí)現(xiàn)
這篇文章主要介紹了匯編程序輸出“Hello world”的實(shí)現(xiàn)，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2020-01-01
使用匯編語言編寫一條簡(jiǎn)單的貪吃蛇的實(shí)現(xiàn)
這篇文章主要介紹了使用匯編語言編寫一條簡(jiǎn)單的貪吃蛇的實(shí)現(xiàn)，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2020-01-01
這篇文章主要為大家介紹了UEFI開發(fā)基礎(chǔ)HII代碼示例詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪2022-06-06
這篇文章主要介紹了iOS匯編入門教程之ARM64匯編基礎(chǔ)教程，本文通過例子給大家介紹的非常詳細(xì)，具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2020-02-02
從匯編代碼開始全面解析synchronized還原最真實(shí)的偏向鎖
這篇文章主要為大家介紹了從模板解釋器匯編源碼開始分析還原最真實(shí)的偏向鎖實(shí)現(xiàn)，解釋monitorenter字節(jié)碼命令的方法開始，從匯編代碼開始全面解析synchronized2022-02-02
本文主要介紹了匯編語言中DIV指令的具體用法2024-03-03
匯編語言（assembly language）是一種用于電子計(jì)算機(jī)、微處理器、微控制器或其他可編程器件的低級(jí)語言，亦稱為符號(hào)語言。這篇文章主要介紹了匯編語言中test和cmp有什么區(qū)別,需要的朋友可以參考下2020-01-01![詳解匯編語言中中括號(hào)[]作用及l(fā)ea和mov指令的區(qū)別](http://img.jbzj.com/images/xgimg/bcimg8.png)
詳解匯編語言中中括號(hào)[]作用及l(fā)ea和mov指令的區(qū)別
這篇文章主要介紹了匯編語言中中括號(hào)[]作用及l(fā)ea和mov指令的區(qū)別,本文分步驟給大家介紹的非常詳細(xì)，具有一定的參考借鑒價(jià)值，需要的朋友可以參考下2020-01-01
這篇文章主要介紹了匯編語言：比較指令、跳轉(zhuǎn)指令、JCC的使用,文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2020-01-01