源自：字節(jié)跳動(dòng)團(tuán)隊(duì)

感謝字節(jié)跳動(dòng)團(tuán)隊(duì)的分享， 本文意在分享此類開發(fā)崩潰知識(shí)，如有涉及侵權(quán)，請(qǐng)聯(lián)系我刪除

ARC 環(huán)境下在多線程中執(zhí)行賦值代碼可能會(huì)產(chǎn)生野指針，導(dǎo)致 EXC_BAD_ACCESS 崩潰。
這種崩潰發(fā)生的概率很低，在開發(fā)和灰度階段即使執(zhí)行到相應(yīng)代碼也很難崩潰，因此容易遺漏到正式環(huán)境。在上億級(jí)用戶的 App 往往會(huì)成為 Top 問題，對(duì)指標(biāo)造成影響，并且很難排查。
今日頭條在治理 Crash 的過程中徹底解決了數(shù)十個(gè)此類崩潰，發(fā)現(xiàn)其具有一定共性。本文詳細(xì)分析崩潰發(fā)生的過程，以及總結(jié)了容易出現(xiàn)問題的場(chǎng)景，希望在大家遇到此類問題時(shí)能提供一些思路。

1. 原理

Objective-C 對(duì)象的賦值過程包含創(chuàng)建新值、保留舊值、加載新值、釋放舊值四步。相比 MRC，ARC 環(huán)境中編譯器會(huì)自動(dòng)插入保留與釋放舊值的步驟：

• • image.png
• • image.png
• • image.png
• • image.png

objc_release 會(huì)減小對(duì)象的引用計(jì)數(shù)，減小到 0 時(shí)對(duì)象就會(huì)被銷毀，假如這時(shí)有其它線程正在使用這個(gè)對(duì)象，那么使用對(duì)象的線程就很可能發(fā)生崩潰。

2. 崩潰場(chǎng)景

Demo設(shè)計(jì)在 B 線程中釋放 A 線程創(chuàng)建的對(duì)象使 C 線程崩潰：

• • image.png

復(fù)現(xiàn)過程：

• • image.png

2. A 線程先創(chuàng)建初始值 _instance

• A 線程執(zhí)行到 _instance = x0， 創(chuàng)建了新值并賦給 _instance；此時(shí) _instance 引用計(jì)數(shù)為 1；

3. B、C 線程讀取到 A 線程創(chuàng)建的初始值 _instance

• B、C 線程分別執(zhí)行到 x1 = _instance 時(shí)，從 _instance 中讀到線程 A 創(chuàng)建的對(duì)象，保存到各自的上下文中；_instance 引用計(jì)數(shù)仍為 1；

4. B 線程釋放 _instance

• B 線程執(zhí)行 objc_release(x1) 后會(huì)釋放 _instance；_instance 引用計(jì)數(shù)變?yōu)?0，被銷毀；

5. C 線程訪問 _instance

• C 線程執(zhí)行到 objc_release(x1) 時(shí)訪問 _instance；由于 _instance 已經(jīng)被銷毀，訪問時(shí)會(huì)發(fā)生崩潰。

3. 崩潰原因

如下圖，為什么會(huì)發(fā)生 EXC_BAD_ACCESS 崩潰？

• • image.png

ldr x17, [x2, #0x20] 指令認(rèn)為寄存器 x2 中存放的是地址，將該地址和 0x20 相加獲得一個(gè)新地址，再?gòu)男碌刂分凶x取 8 字節(jié)存放到 x17 中。
本例中可以分析出寄存器 x2 存放的是 Class 的地址，x2+0x20 是 Class 的成員變量 bits 的地址，這個(gè)地址是 0x00000007374040e0。從這個(gè)地址中讀值時(shí)操作系統(tǒng)發(fā)現(xiàn)它是非法內(nèi)存地址，從而產(chǎn)生 EXC_BAD_ACCESS 異常并報(bào)出這個(gè)錯(cuò)誤地址。
附：Class 的結(jié)構(gòu)體及成員變量的偏移

• • image.png

為什么 Class->bits 的地址會(huì)是 0x00000007374040e0 ，這個(gè)非法地址是怎么來的？

_instance 對(duì)象被銷毀后，內(nèi)存被系統(tǒng)隨機(jī)改寫，通過崩潰截圖中 lldb 打印的日志可知：

對(duì)象的 ISA 位置存放的隨機(jī)值是 0x000010d7374040c0

• Class = ISA & ISA_MASK = 0x00000007374040c0
• Class->bits = 0x00000007374040c0 + 0x20 = 0x00000007374040e0
• ISA 是隨機(jī)值，那么 Class、Class->bits 也都是隨機(jī)值，很容易是一個(gè)非法的內(nèi)存地址，訪問非法內(nèi)存地址就會(huì)產(chǎn)生 EXC_BAD_ACCESS 異常。

在執(zhí)行 objc_release 函數(shù)之前 _instance 就已經(jīng)銷毀了，為什么執(zhí)行到 ldr x17, [x2, #0x20] 這一行指令時(shí)才發(fā)生崩潰，之前沒有崩潰？

EXC_BAD_ACCESS 異常發(fā)生在訪問非法內(nèi)存地址時(shí)。在 ldr x17, [x2, #0x20] 之前僅有 ldr x16, [x0] 中使用方括號(hào) [] 訪問了 x0 中存儲(chǔ)的地址。此時(shí) x0 中存儲(chǔ)的是 _instance 的地址，_instance 銷毀后對(duì)象的內(nèi)存被系統(tǒng)隨機(jī)改寫，而 x0 中的地址是之前就存進(jìn)來的合法地址，訪問合法地址不會(huì)出現(xiàn)異常。

4.更多崩潰場(chǎng)景

上述崩潰發(fā)生在 objc_release 堆棧中，但實(shí)際可能發(fā)生在任意堆棧，這與 _instance 使用的場(chǎng)景有關(guān)。下面構(gòu)造了一些常見的崩潰堆棧，感興趣的讀者可以參照復(fù)現(xiàn)。

4.1崩潰在 objc_retain 中

• • image.png
• • image.png

崩潰原因：_instance 作為參數(shù)傳遞到 bar 函數(shù)，在函數(shù)開始執(zhí)行時(shí)會(huì)保留參數(shù) objc_reatin(_instance)，結(jié)束執(zhí)行時(shí)會(huì)釋放參數(shù)objc_release(_instance)。若保留參數(shù)時(shí) _instance 已被其它線程銷毀，就會(huì)導(dǎo)致崩潰在 objc_reatin 中。

4.2 崩潰在 objc_msgSend 中

• • image.png
• • image.png

崩潰原因：第 7 行代碼向 _instance 發(fā)送了 isEqual: 消息，在執(zhí)行到崩潰指令 ldr x11,[x16, #0x10] 時(shí)，寄存器 x16 存放的是 _instance 的 Class，[x16, #0x10] 指令想要讀取 Class->cache，進(jìn)而從 cache 中尋找緩存的方法。_instance 銷毀后 ISA、Class、Class->cache 會(huì)成為隨機(jī)值，如果 Class->cache 是非法地址，在執(zhí)行 [x16, #0x10] 時(shí)就會(huì)崩潰。

4.3 崩潰在 objc_autoreleasePoolPop 中

• • image.png
• • image.png

崩潰原因：若對(duì)象使用非 new/alloc/copy/mutableCopy 開頭的接口創(chuàng)建，并且不滿足 Autorelease elision [3] 策略，會(huì)被添加到自動(dòng)釋放池中。本例創(chuàng)建的 _instance 被添加到子線程的自動(dòng)釋放池中，子線程任務(wù)執(zhí)行完成后會(huì)對(duì)池中的對(duì)象 pop，依次調(diào)用 objc_release 進(jìn)行釋放，若次此時(shí) _instance 已在其它線程中銷毀，就會(huì)發(fā)生崩潰。

4.4 EXC_BREAKPOINT 崩潰

• • image.png
• • image.png

崩潰原因：-[NSString stringWithFormat:@"%@",_instance] 會(huì)調(diào)用 objc_opt_respondsToSelector 函數(shù)并將 _instance 作為參數(shù)傳入。在 objc_opt_respondsToSelector 函數(shù)發(fā)生崩潰前，x16 存儲(chǔ)的是參數(shù) _instance 的 Class。

指針認(rèn)證 [4] 相關(guān)的指令會(huì)使 x16 寄存器與 x17 寄存器相等，然后用 xpacd x17 對(duì) x17 寄存器中高位清零，再比較 x16 與 x17，不相等則執(zhí)行 brk 指令觸發(fā) EXC_BREAKPOINT 異常。xpacd 對(duì)合法指針清零不會(huì)改變指針的值，不會(huì)執(zhí)行 brk 指令產(chǎn)生異常。當(dāng)參數(shù)被銷毀后，x16 可能被改寫為非法指針并賦給 x17，xpacd x17 對(duì)非法指針高位清零會(huì)改變 x17，使 x17 不等于 x16，導(dǎo)致 EXC_BREAKPOINT 異常。

5. 常見典型業(yè)務(wù)場(chǎng)景

5.1 場(chǎng)景一 對(duì)全局變量賦值

• • image.png

這段代碼定義了全局變量 geckoSettingDict，并在在一個(gè)懶加載方法中對(duì)它初始化。最初這段代碼正常運(yùn)行在于 A 業(yè)務(wù)中，后面被 B 業(yè)務(wù)拷貝走，B 業(yè)務(wù)存在多線程調(diào)用的場(chǎng)景，在 geckoSettingDict 未初始化時(shí)，多個(gè)線程可以同時(shí)進(jìn)入 if (geckoSettingDict == nil) 對(duì) geckoSettingDict 賦值，導(dǎo)致 geckoSettingDict 被提前銷毀產(chǎn)生崩潰。

由于使用了 dictionaryWithContestOfFile: 接口初始化，geckoSettingDict 會(huì)被添加到自動(dòng)釋放池中，導(dǎo)致崩潰發(fā)生在 objc_autoreleasePoolPop 堆棧里，很難追查。這個(gè)問題困擾頭條半年之久，最終借助字節(jié)內(nèi)部 APM 提供的線上工具定位到原因：

• • image.png

小結(jié)：

• 這類問題常見于開發(fā)者設(shè)計(jì)了全局變量，并在對(duì)外暴露的接口中對(duì)全局變量進(jìn)行賦值，開發(fā)者預(yù)期變量只會(huì)初始化一次，但實(shí)際接口被調(diào)用的環(huán)境不可控
• 修復(fù)建議：使用 dispatch_once，保證全局變量只被賦值一次。

5.2 場(chǎng)景二 對(duì)屬性賦值

• • image.png

某類設(shè)計(jì)了屬性 extraParam 用于保存透?jìng)鲄?shù)，并在 updateExtraParams: 方法中更新該屬性。最初 updateExtraParams: 也在多線程中被調(diào)用，但沒有造成很大影響，某次需求增大了它被同時(shí)調(diào)用的概率，引發(fā)了大面積的崩潰。

小結(jié)：

• 這類問題常見于類向外部提供了接口來更新成員變量，但接口被調(diào)用的環(huán)境不可控。
• 單例的屬性更容易被外界訪問，更容易在多線程下出現(xiàn)賦值，因此這類問題也最多。
• 修復(fù)建議：涉及多線程修改的屬性，使用 atomic 修飾。

5.3 場(chǎng)景三 屬性懶加載

• • image.png

某類在懶加載方法中對(duì) _interceptUrls 賦值，在 addADparamsToRequest 方法中調(diào)用 self.interceptUrls 觸發(fā)懶加載。由于業(yè)務(wù)環(huán)境復(fù)雜，addADparamsToRequest 在主線程、網(wǎng)絡(luò)回調(diào)線程、通知線程等多個(gè)場(chǎng)景中被調(diào)用，多線程下同時(shí)對(duì) _interceptUrls 賦值導(dǎo)致它被提前銷毀，產(chǎn)生崩潰。

修復(fù)辦法是將 _interceptUrls 的初始化放在 init 方法中，保證它只被賦值一次。

• • image.png

案例2

image.png

某類在懶加載方法中對(duì) _userCache 賦值，在 cacheUserInfo:、removeCachedUserInfo:等 4 個(gè)方法中都調(diào)用了 self.userCache 觸發(fā)懶加載，這 4 個(gè)方法可能同時(shí)被多個(gè)線程調(diào)用，很容易出現(xiàn)多線程環(huán)境下對(duì) _userCache 賦值，導(dǎo)致它提前銷毀。解決辦法是將 _userCache 初始化放在 init 中，保證它只會(huì)被賦值一次。

小結(jié)：

• 這是類場(chǎng)景比上述場(chǎng)景都更加隱蔽，在設(shè)計(jì)懶加載方法時(shí)要考慮觸發(fā)懶加載的方法是否會(huì)在多線程環(huán)境中被調(diào)用。
• 修復(fù)建議：如果懶加載屬性會(huì)被多線程訪問到，就不要使用懶加載，直接在 init 方法中初始化，保證賦值的代碼只會(huì)被一個(gè)線程訪問。

6.如何分析此類崩潰？

• 有業(yè)務(wù)代碼堆棧的崩潰，可以通過反匯編推斷出具體崩潰的對(duì)象；在工程中檢索對(duì)該對(duì)象賦值的代碼是否存在多線程調(diào)用，如果存在就基本可以確認(rèn)崩潰原因是多線程賦值導(dǎo)致。
• 純系統(tǒng)堆棧的崩潰，如發(fā)生在 objc_autoreleasePoolPop 堆棧的崩潰。通過反匯編只能推斷出是某個(gè)對(duì)象被 over-release 了，無法推斷出具體是哪個(gè)對(duì)象。字節(jié)內(nèi)部的同學(xué)可以使用 APM 提供的 Zombie、GWPASan、Coredump 等線上工具 [5]進(jìn)行排查；如果沒有線上工具，需要找到與該崩潰同一版本/時(shí)間段上漲的其它野指針崩潰，它們有可能是同一個(gè)原因?qū)е碌?，從有業(yè)務(wù)代碼堆棧的崩潰入手去排查。

7. 參考：文獻(xiàn)

[1] Objective-C Automatic Reference Counting (ARC) — Clang 16.0.0git documentation (https://clang.llvm.org/docs/AutomaticReferenceCounting.html#semantics)

[2] LLDB Tutorial (https://opensource.apple.com/source/lldb/lldb-310.2.36/www/tutorial.html)

[3] WWDC22: Improve app size and runtime performance - 掘金 (https://juejin.cn/post/7135344206939160612#heading-5)

[4] ARM-指針認(rèn)證 (http://www.itdecent.cn/p/62bf046b7701)

[5] 字節(jié)跳動(dòng)如何系統(tǒng)性治理 iOS 穩(wěn)定性問題 (https://juejin.cn/post/7034418275728097288)