快捷導(dǎo)航

NSMutable?對(duì)象的坑解決分析

更新時(shí)間：2023年02月28日 16:24:02 作者：yuec

這篇文章主要為大家介紹了NSMutable?對(duì)象的坑解決分析，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪

背景

最近處理了兩個(gè)崩潰，都是在 NSMutableSet 調(diào)用 enumerateObjectsWithOptions 的時(shí)候發(fā)生的，崩潰類型懸垂指針。查看崩潰堆棧里面的業(yè)務(wù)代碼，發(fā)現(xiàn) set 有 removeObject 和 addObject 的操作，按照經(jīng)驗(yàn)來(lái)講這大概率是一個(gè)多線程操作 set 造成的。最開(kāi)始懷疑的是 removeObject 導(dǎo)致遍歷的時(shí)候訪問(wèn)到了 release的 obj 對(duì)象。但是當(dāng)保證 removeObject 和 enumerateObjectsWithOptions 在同一個(gè) queue 執(zhí)行的時(shí)候崩潰仍然存在。

測(cè)試代碼

嘗試暴力復(fù)現(xiàn)，測(cè)試 addObject 和 enumerateObjectsWithOptions 是否存在多線程訪問(wèn)的問(wèn)題。

NSMutableSet *_set = [NSMutableSet set];
dispatch_async(dispatch_queue_create("queue", 0x0), ^{
  for (int i = 0; i < 10000; i++) {
    [_set enumerateObjectsUsingBlock:^(id  _Nonnull obj, BOOL * _Nonnull stop) {}];
  }
});
for (int i = 0; i < 10000; i++) {
  [_set addObject:[NSObject new]];
}

復(fù)現(xiàn)了崩潰，非法地址訪問(wèn)，崩潰地址 0x14ff1f228

崩潰時(shí)的匯編指令和 x22 寄存器相關(guān)。

    0x18a6cb260 <+148>: mov    w24, #0x0
    0x18a6cb264 <+152>: adrp   x25, 358888
    0x18a6cb268 <+156>: add    x25, x25, #0xd90          ; ___NSSetM_DeletedMarker
->  0x18a6cb26c <+160>: ldr    x20, [x22, w24, uxtw #3]
    0x18a6cb270 <+164>: cmp    x20, #0x0
    0x18a6cb274 <+168>: ccmp   x20, x25, #0x4, ne

再次執(zhí)行測(cè)試代碼，斷點(diǎn)到崩潰地址 0x18a6cb26c，此時(shí) x22 的值 0x0000000280567d00，

_set 的地址 0x0000000280098560。

memory read _set:

x22 這個(gè)值在 _set + 0x10 的位置。對(duì) _set + 0x10 處添加內(nèi)存斷點(diǎn)查看修改這個(gè)值的邏輯。

(lldb) watchpoint set expression -w write -- 0x0000000282963fd0
Watchpoint created: Watchpoint 1: addr = 0x282963fd0 size = 8 state = enabled type = w
    new value: 4730418656

內(nèi)存斷點(diǎn)發(fā)現(xiàn) set 在執(zhí)行 addObject 可能會(huì)觸發(fā) __rehashs 方法，__rehashs 會(huì)修改 _set + 0x10 處的值。

#0	0x000000018a64a578 in __rehashs ()
#1	0x000000018a64b96c in -[__NSSetM addObject:] ()
#2	0x0000000102718990 in -[ViewController viewDidLoad] at /Users/yuencong/workplace/Test/Test/ViewController.mm:23

__rehashs 修改 _set + 0x10 上方 0x18a64a568 處有一次 free 的操作：

    0x18a64a564 <+212>: mov    x0, x22
    0x18a64a568 <+216>: bl     0x18a7fc7d0               ; symbol stub for: free
    0x18a64a56c <+220>: ldrsw  x8, [x25, #0x680]
    0x18a64a570 <+224>: add    x8, x20, x8
->  0x18a64a574 <+228>: str    x21, [x8]
    0x18a64a578 <+232>: ldr    w9, [x8, #0xc]
    0x18a64a57c <+236>: bfi    w9, w19, #26, #6
    0x18a64a580 <+240>: str    w9, [x8, #0xc]

再次運(yùn)行測(cè)試代碼，查看 free 的值，斷點(diǎn)到 0x18a64a568:

    0x18a64a560 <+208>: b.ne   0x18a64a518               ; <+136>
    0x18a64a564 <+212>: mov    x0, x22
->  0x18a64a568 <+216>: bl     0x18a7fc7d0               ; symbol stub for: free
    0x18a64a56c <+220>: ldrsw  x8, [x25, #0x680]
    0x18a64a570 <+224>: add    x8, x20, x8
    0x18a64a574 <+228>: str    x21, [x8]

可以看到 free 的 x22 的值，也是 _set + 0x10 位置的值。

(lldb) register read x22
     x22 = 0x0000000282d245c0
(lldb) _set __NSSetM * 3 elements 0x0000000282d24580
error: '_set' is not a valid command.
(lldb) memory read 0x0000000282d24590
0x282d24590: c0 45 d2 82 02 00 00 00 05 00 00 00 03 00 00 04  .E..............
0x282d245a0: 80 00 32 80 02 00 00 00 00 00 00 00 00 00 00 00  ..2.............

_set +0x10 處是個(gè)啥？

打印 OBJC_CLASS$___NSSetM 的 ivars，offset == 0x10 的位置是 storage

ivars          0x593140 __OBJC_$_INSTANCE_VARIABLES___NSSetM
  entsize   32
  count     2
  offset    0x59b3d8 _OBJC_IVAR_$___NSSetM.cow 8
  name      0x39fe21 cow
            type      0x3ff0ab A^{__cow_state_t}
alignment 3
  size      8
  offset    0x59b3d0 _OBJC_IVAR_$___NSSetM.storage 16
  name      0x39fe25 storage
            type      0x400612 {?="objs"^@"state"(?="mutations"Q""{?="muts"I"used"b26"szidx"b6})}
alignment 3
  size      16

這個(gè) type 略長(zhǎng)，沒(méi)有分析具體的類型，但是根據(jù) xcode debug 的信息，可以得知 storage 存儲(chǔ)了一個(gè)指針，指針指向存儲(chǔ) set item 的數(shù)組，這個(gè)字段的含義也就比較容易理解了。

結(jié)論

NSMutableSet 對(duì)象 addObject 可能會(huì)觸發(fā) __rehashs，_rehashs 會(huì)釋放 storage 指針， enumerateObjectsUsingBlock 會(huì)訪問(wèn) storage 指針，多線程訪問(wèn)的情況下會(huì)觸發(fā) use-after-free的崩潰。如果存在多線程同時(shí)執(zhí)行 enumerateObjectsUsingBlock 和 addObject 方法需要保證線程安全。