日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關咨詢
選擇下列產(chǎn)品馬上在線溝通
服務時間：8:30-17:00
你可能遇到了下面的問題
關閉右側工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
頭條穩(wěn)定性治理：ARC環(huán)境中對Objective-C對象賦值的Crash隱患

ARC 環(huán)境下在多線程中執(zhí)行賦值代碼可能會產(chǎn)生野指針，導致 EXC_BAD_ACCESS 崩潰。

坡頭ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應用場景，ssl證書未來市場廣闊！成為成都創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書合作）期待與您的合作！

這種崩潰發(fā)生的概率很低，在開發(fā)和灰度階段即使執(zhí)行到相應代碼也很難崩潰，因此容易遺漏到正式環(huán)境。在上億級用戶的 App 往往會成為 Top 問題，對指標造成影響，并且很難排查。

今日頭條在治理 Crash 的過程中徹底解決了數(shù)十個此類崩潰，發(fā)現(xiàn)其具有一定共性。本文詳細分析崩潰發(fā)生的過程，以及總結了容易出現(xiàn)問題的場景，希望在大家遇到此類問題時能提供一些思路。

一. 原理

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

NSObject *_instance;
void foo(void) {
    _instance = [[NSObject alloc] init];
}

這點在 AutomaticReferenceCounting [1] 文檔中有提到，通過匯編代碼也可以分析：

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

二. 崩潰場景

為了演示僅一行賦值代碼就能造成崩潰，以及清晰地分析崩潰的原因，我設計了一個 Demo，在 B 線程中釋放 A 線程創(chuàng)建的對象使 C 線程崩潰：

復現(xiàn)過程：

  1. A、B、C 三個線程同時進入??foo?? 函數(shù)
  2. A 線程先創(chuàng)建初始值 _instance
    A 線程執(zhí)行到 _instance = x0， 創(chuàng)建了新值并賦給 _instance；此時 _instance 引用計數(shù)為 1；
  3. B、C 線程讀取到 A 線程創(chuàng)建的初始值 _instance
    B、C 線程分別執(zhí)行到 x1 = _instance 時，從 _instance 中讀到線程 A 創(chuàng)建的對象，保存到各自的上下文中；_instance 引用計數(shù)仍為 1；
  4. B 線程釋放 _instance
    B 線程執(zhí)行???objc_release(x1)?? 后會釋放 _instance；_instance 引用計數(shù)變?yōu)?0，被銷毀；
  5. C 線程訪問 _instance
    C 線程執(zhí)行到???objc_release(x1)?? 時訪問 _instance；由于 _instance 已經(jīng)被銷毀，訪問時會發(fā)生崩潰。

使用 lldb 的 thread continue 指令 [2] 來控制整個流程，它可以僅讓一個線程執(zhí)行，其它線程保持掛起。

  1. 3 個線程同時進入??foo??? 函數(shù)操作步驟：在??foo??? 函數(shù)里面打上斷點，可以多次測試讓 3 個線程同時進入斷點。如圖，線程 2 3 4 同時進入了??foo?? 函數(shù)：

  1. 線程 2 執(zhí)行到 _instance = x0，創(chuàng)建初始值并賦給 _instance操作步驟：在 Thread 2 中給匯編代碼第 10 行打斷點，執(zhí)行 thread continue，使 Thread 2 執(zhí)行完 _instance = x0。可以看到 Thread 2 創(chuàng)建的實例為 0x000000002813e400：

  1. 線程 3、4 執(zhí)行到 x1 = _instance，讀取到線程 2 創(chuàng)建的 _instance操作步驟 1：刪除所有斷點，切換到 Thread 3 ，給第 9 行打斷點，執(zhí)行 thread continue操作步驟 2：刪除斷點，切換到 Thread 4，給第 9 行打斷點，執(zhí)行 thread continue線程 3、4 從 _instance 中讀到了線程 2 創(chuàng)建的 _instance 0x000000002813e400：

  1. 線程 3 執(zhí)行完 objc_release，_instance 引用計數(shù)變?yōu)?0，被銷毀操作步驟：刪除斷點，切換到 Thread 3，給第 12 行打斷點，執(zhí)行 thread continue。執(zhí)行后打印 0x000000002813e400 出現(xiàn)隨機值，說明 _instance 已經(jīng)被銷毀：

  1. 線程 4 執(zhí)行 objc_release，訪問被銷毀的 _instance，出現(xiàn)崩潰操作步驟：刪除斷點，切換到 Thread 4，給第 12 行打斷點，執(zhí)行 thread continue。由于 _instance 已經(jīng)被銷毀，再次訪問它時發(fā)生 EXC_BAD_ACCESS 崩潰。

三. 崩潰原因

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

??ldr x17, [x2, #0x20]?? 指令認為寄存器 x2 中存放的是地址，將該地址和 0x20 相加獲得一個新地址，再從新地址中讀取 8 字節(jié)存放到 x17 中。

本例中可以分析出寄存器 x2 存放的是 Class 的地址，x2+0x20 是 Class 的成員變量 bits 的地址，這個地址是 ??0x00000007374040e0??。從這個地址中讀值時操作系統(tǒng)發(fā)現(xiàn)它是非法內(nèi)存地址，從而產(chǎn)生 EXC_BAD_ACCESS 異常并報出這個錯誤地址。

附：Class 的結構體及成員變量的偏移

為什么 Class->bits 的地址會是 ??0x00000007374040e0?? ，這個非法地址是怎么來的？

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

  • 對象的 ISA 位置存放的隨機值是 0x000010d7374040c0
  • Class = ISA & ISA_MASK = 0x00000007374040c0
  • Class->bits = 0x00000007374040c0 + 0x20 =??0x00000007374040e0??

ISA 是隨機值，那么 Class、Class->bits 也都是隨機值，很容易是一個非法的內(nèi)存地址，訪問非法內(nèi)存地址就會產(chǎn)生 EXC_BAD_ACCESS 異常。

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

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

四. 更多崩潰場景

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

4.1 崩潰在 objc_retain 中

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

4.2 崩潰在 objc_msgSend 中

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

4.3  崩潰在 objc_autoreleasePoolPop 中

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

4.4  EXC_BREAKPOINT 崩潰

除了上面提到的 EXC_BAD_ACCESS 異常，這類問題也能導致其它類型的異常，這里舉一個 EXC_BREAKPOINT 異常的例子。

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

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

五. 典型業(yè)務場景

業(yè)務中有三種常見導致崩潰的場景，本文從每個場景中挑選了兩個典型案例。

5.1 場景一 對全局變量賦值

典型案例 1

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

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

修復辦法是使用 dispatch_once 保證 geckoSettingDict 只賦值一次：

典型案例 2

在圖片監(jiān)控的組中件， queue 被設計為全局變量，在 ??startImageMonitor:??? 中對它初始化，這是啟動監(jiān)控功能的方法，調(diào)用一次就可以了。但使用方在某次改動中，無意間在另一個線程中多調(diào)用了一次 ??startImageMonitor:?? 方法，使 queue 被同時賦值了兩次，導致它提前銷毀。

另一線程在使用 ??dispatch_async(queue,^{})?? 接口時，由于 queue 已經(jīng)被銷毀，在 dispatch_async 堆棧中發(fā)生崩潰：

崩潰在 ldr x3, [x16, #0x58] 是因為 x16 存儲的是 dispatch_async 的參數(shù) queue，queue 被銷毀后，queue + 0x58 可能是一個非法內(nèi)存地址，從該非法地址讀值會導致異常。

修復辦法是業(yè)務方調(diào)整了調(diào)用邏輯，圖片監(jiān)控組件中也優(yōu)化了代碼，使用 dispatch_once 保證 queue 只能賦值一次。

場景小結

這類問題常見于開發(fā)者設計了全局變量，并在對外暴露的接口中對全局變量進行賦值，開發(fā)者預期變量只會初始化一次，但實際接口被調(diào)用的環(huán)境不可控。

修復建議：使用 dispatch_once，保證全局變量只被賦值一次。

5.2 場景二 對屬性賦值

典型案例 1

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

典型案例 2

A 業(yè)務設計了單例類 Configure 并提供了對外的屬性 autoResolutionParams。B 業(yè)務對 Configure 的屬性 autoResolutionParams 重新賦值使它被銷毀，導致其它正在使用 autoResolutionParams 的線程崩潰。

場景小結

這類問題常見于類向外部提供了接口來更新成員變量，但接口被調(diào)用的環(huán)境不可控。

單例的屬性更容易被外界訪問，更容易在多線程下出現(xiàn)賦值，因此這類問題也最多。

修復建議：涉及多線程修改的屬性，使用 atomic 修飾。

5.3 場景三 屬性懶加載

典型案例 1

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

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

典型案例 2

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

場景小結

這是類場景比上述場景都更加隱蔽，在設計懶加載方法時要考慮觸發(fā)懶加載的方法是否會在多線程環(huán)境中被調(diào)用。

修復建議：如果懶加載屬性會被多線程訪問到，就不要使用懶加載，直接在 init 方法中初始化，保證賦值的代碼只會被一個線程訪問。

六. 總結

產(chǎn)生這類崩潰的原因雖然簡單，但是在大型 App 中很難避免。隨著業(yè)務方增多、觸發(fā)賦值代碼的接口增多，調(diào)用環(huán)境會更復雜；而且也存在相似代碼 copy ，從無問題環(huán)境 copy 到有問題環(huán)境，很容易出現(xiàn)多線程環(huán)境下同時給對象賦值，導致舊值被過度釋放。

在分析此類崩潰堆棧時，往往很難注意到是賦值時 ARC 添加的 objc_release 指令使舊值被過度釋放導致的，并且線下也基本無法復現(xiàn)，因此這類野指針問題也容易成為懸案。熟悉原理和常見場景有助于排查問題，更有助于在開發(fā)階段就設計穩(wěn)健的代碼。

七. 答疑

  1. EXC_BAD_ACCESS 是否都是這種問題導致的？
  • 不是，訪問非法內(nèi)存地址就會報 EXC_BAD_ACCESS 錯誤。
  • 但根據(jù)經(jīng)驗來看，非多線程導致的問題在開發(fā)和測試環(huán)境中比較容易復現(xiàn)，在上線前基本都會被修復，上線后才爆發(fā)出來的野指針問題 80% 都是這個原因。
  1. 如何分析此類崩潰？
  • 有業(yè)務代碼堆棧的崩潰，可以通過反匯編推斷出具體崩潰的對象；在工程中檢索對該對象賦值的代碼是否存在多線程調(diào)用，如果存在就基本可以確認崩潰原因是多線程賦值導致。
  • 純系統(tǒng)堆棧的崩潰，如發(fā)生在 objc_autoreleasePoolPop 堆棧的崩潰。通過反匯編只能推斷出是某個對象被 over-release 了，無法推斷出具體是哪個對象。字節(jié)內(nèi)部的同學可以使用 APM 提供的 Zombie、GWPASan、Coredump 等線上工具 [5]進行排查；如果沒有線上工具，需要找到與該崩潰同一版本/時間段上漲的其它野指針崩潰，它們有可能是同一個原因導致的，從有業(yè)務代碼堆棧的崩潰入手去排查。

八. 加入我們

我們是字節(jié)跳動產(chǎn)品研發(fā)和工程架構部-頭條-客戶端基礎技術-iOS 團隊，在性能優(yōu)化、基礎組件、業(yè)務架構、研發(fā)體系、安全合規(guī)、線下質(zhì)量基礎設施、線上問題定位歸因平臺等方向深耕，負責保障和提升今日頭條、西瓜視頻和番茄小說的產(chǎn)品質(zhì)量與開發(fā)效率，聚焦于此的同時向外延伸。

如果你對技術充滿熱情，喜歡追求極致，渴望用自己的代碼改變數(shù)億用戶的體驗，歡迎加入我們。目前我們在北京、深圳、廣州均有招聘需求，簡歷投遞郵箱：chenjun.jonas@bytedance.com；郵件標題：姓名-工作年限-產(chǎn)品研發(fā)和工程架構部-頭條-客戶端基礎技術-iOS/Android。

九. 參考文獻

[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-指針認證  (https://www.jianshu.com/p/62bf046b7701)

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


當前標題：頭條穩(wěn)定性治理：ARC環(huán)境中對Objective-C對象賦值的Crash隱患
分享網(wǎng)址：http://www.5511xx.com/article/cdipcih.html