先看一下收到的crash堆棧
完全是系統(tǒng)函數(shù)，不能簡(jiǎn)單的從自身代碼找問(wèn)題。
先看一下錯(cuò)誤原因，SEGV_ACCERR是內(nèi)存訪問(wèn)失敗的錯(cuò)誤，一般是對(duì)象被釋放的情況比較多。不過(guò)這個(gè)堆棧全部是系統(tǒng)函數(shù)，比較難判斷是那個(gè)對(duì)象被釋放了。
堆棧里唯一比較眼熟的是 -[AVPlayerItemVideoOutput _dispatchOutputMediaDataWillChange] , 所以我們看一下這個(gè)方法的匯編代碼
(lldb) dis -n '-[AVPlayerItemVideoOutput _dispatchOutputMediaDataWillChange]'
AVFoundation`-[AVPlayerItemVideoOutput _dispatchOutputMediaDataWillChange]:
0x188fbb8c0 <+0>: sub sp, sp, #0x60 ; =0x60
0x188fbb8c4 <+4>: stp x22, x21, [sp, #0x30]
0x188fbb8c8 <+8>: stp x20, x19, [sp, #0x40]
0x188fbb8cc <+12>: stp x29, x30, [sp, #0x50]
0x188fbb8d0 <+16>: add x29, sp, #0x50 ; =0x50
0x188fbb8d4 <+20>: mov x19, x0
0x188fbb8d8 <+24>: adrp x8, 176802
0x188fbb8dc <+28>: ldrsw x20, [x8, #0x244]
0x188fbb8e0 <+32>: ldr x8, [x19, x20]
0x188fbb8e4 <+36>: adrp x21, 176802
0x188fbb8e8 <+40>: ldrsw x9, [x21, #0x230]
0x188fbb8ec <+44>: ldrb w9, [x8, x9]
0x188fbb8f0 <+48>: cbnz w9, 0x188fbb904 ; <+68>
0x188fbb8f4 <+52>: adrp x9, 176802
0x188fbb8f8 <+56>: ldrsw x9, [x9, #0x228]
0x188fbb8fc <+60>: ldrb w9, [x8, x9]
0x188fbb900 <+64>: cbz w9, 0x188fbb960 ; <+160>
0x188fbb904 <+68>: adrp x9, 176802
0x188fbb908 <+72>: ldrsw x9, [x9, #0x214]
0x188fbb90c <+76>: ldr x9, [x8, x9]
0x188fbb910 <+80>: cbz x9, 0x188fbb960 ; <+160>
0x188fbb914 <+84>: adrp x10, 176802
0x188fbb918 <+88>: ldrsw x10, [x10, #0x21c]
0x188fbb91c <+92>: ldr x0, [x8, x10]
0x188fbb920 <+96>: adrp x8, 153392
0x188fbb924 <+100>: ldr x8, [x8, #0x6e0]
0x188fbb928 <+104>: str x8, [sp]
0x188fbb92c <+108>: adrp x8, 91
0x188fbb930 <+112>: ldr d0, [x8, #0x260]
0x188fbb934 <+116>: str d0, [sp, #0x8]
0x188fbb938 <+120>: adrp x8, 0
0x188fbb93c <+124>: add x8, x8, #0x99c ; =0x99c
0x188fbb940 <+128>: str x8, [sp, #0x10]
0x188fbb944 <+132>: adrp x8, 153408
0x188fbb948 <+136>: add x8, x8, #0xcb8 ; =0xcb8
0x188fbb94c <+140>: stp x8, x9, [sp, #0x18]
0x188fbb950 <+144>: str x19, [sp, #0x28]
0x188fbb954 <+148>: mov x1, sp
0x188fbb958 <+152>: bl 0x189014094 ; symbol stub for: __46-[AVCaptureMetadataOutput _updateRemoteQueue:]_block_invoke
0x188fbb95c <+156>: ldr x8, [x19, x20]
0x188fbb960 <+160>: adrp x9, 176802
0x188fbb964 <+164>: ldrsw x9, [x9, #0x224]
0x188fbb968 <+168>: str xzr, [x8, x9]
0x188fbb96c <+172>: ldr x8, [x19, x20]
0x188fbb970 <+176>: adrp x9, 176802
0x188fbb974 <+180>: ldrsw x9, [x9, #0x228]
0x188fbb978 <+184>: strb wzr, [x8, x9]
0x188fbb97c <+188>: ldr x8, [x19, x20]
0x188fbb980 <+192>: ldrsw x9, [x21, #0x230]
0x188fbb984 <+196>: strb wzr, [x8, x9]
0x188fbb988 <+200>: ldp x29, x30, [sp, #0x50]
0x188fbb98c <+204>: ldp x20, x19, [sp, #0x40]
0x188fbb990 <+208>: ldp x22, x21, [sp, #0x30]
0x188fbb994 <+212>: add sp, sp, #0x60 ; =0x60
0x188fbb998 <+216>: ret
第152行有一個(gè)很關(guān)鍵的提示
symbol stub for: __46-[AVCaptureMetadataOutput _updateRemoteQueue:]_block_invoke
根據(jù)名字可以發(fā)現(xiàn)，應(yīng)該是在block里調(diào)用了 _updateRemoteQueue: 方法，_updateRemoteQueue: 在調(diào)用dispatch_async時(shí)出錯(cuò)，很可能是queue被釋放了。
項(xiàng)目里代碼用到AVPlayerItemVideoOutput是這樣寫(xiě)的
_myVideoOutputQueue = dispatch_queue_create("myVideoOutputQueue", DISPATCH_QUEUE_SERIAL);
[_videoOutput setDelegate:self queue:_myVideoOutputQueue];
在釋放的時(shí)候直接這樣寫(xiě)的
[_player.currentItem removeOutput:_videoOutput];
_myVideoOutputQueue = nil;
[_play pause];
_myVideoOutputQueue都是在主線程使用，正常釋放。
再看AVPlayerItemOutput的接口聲明
/*!
@property delegateQueue
@abstract The dispatch queue where the delegate is messaged.
*/
@property (nonatomic, readonly, nullable) dispatch_queue_t delegateQueue;
看到這里心里大概就有數(shù)了，delegateQueue被聲明為nonatomic，當(dāng)對(duì)象被釋放時(shí)，另一個(gè)線程訪問(wèn)就可能出現(xiàn)問(wèn)題。
為什么nonatomic會(huì)有線程安全問(wèn)題？這要看一下objc的源碼
id objc_getProperty(id self, SEL _cmd, ptrdiff_t offset, BOOL atomic) {
if (offset == 0) {
return object_getClass(self);
}
// Retain release world
id *slot = (id*) ((char*)self + offset);
if (!atomic) return *slot;
// Atomic retain release world
spinlock_t& slotlock = PropertyLocks[slot];
slotlock.lock();
id value = objc_retain(*slot);
slotlock.unlock();
// for performance, we (safely) issue the autorelease OUTSIDE of the spinlock.
return objc_autoreleaseReturnValue(value);
}
nonatomic取到函數(shù)地址后，直接返回指針指向的值，如果這時(shí) *slot 正好被釋放，那么返回的就是一個(gè)錯(cuò)誤的值；而atomic會(huì)先retain，然后放到自動(dòng)釋放池，這樣就能保證返回的對(duì)象一定不會(huì)被釋放。
這里正好想到前幾天另一個(gè)出現(xiàn)概率很大的crash
#59 Thread
SIGSEGV
SEGV_ACCERR
解析原始
0 libobjc.A.dylib objc_msgSend (respondsToSelector:) + 16
1 libdispatch.dylib __dispatch_call_block_and_release + 24
2 libdispatch.dylib __dispatch_client_callout + 16
3 libdispatch.dylib __dispatch_lane_serial_drain$VARIANT$mp + 592
4 libdispatch.dylib __dispatch_lane_invoke$VARIANT$mp + 428
5 libdispatch.dylib __dispatch_workloop_worker_thread + 596
6 libsystem_pthread.dylib _pthread_wqthread + 300
7 libsystem_pthread.dylib start_wqthread + 0
看上去是在一個(gè)gcd的block里，調(diào)用了respondsToSelector:，很顯然是一個(gè)delegate。項(xiàng)目里所有的delegate都是weak聲明的，理論上不會(huì)出現(xiàn)指針懸空的問(wèn)題，直到我看到了這一行
@interface AVPlayerItemVideoOutput : AVPlayerItemOutput
/*!
@property delegate
@abstract The receiver's delegate.
*/
@property (nonatomic, readonly, assign, nullable) id<AVPlayerItemOutputPullDelegate> delegate;
@end
delegate的這種錯(cuò)誤是很多年前才會(huì)有的，沒(méi)想到這竟然出自官方代碼。
UIKit的屬性都是聲明為nonatomic，因?yàn)槎际窃谥骶€程調(diào)用，所以不加鎖其實(shí)是可以接受的，但是音視頻很多都是在非主線程操作的，為了安全犧牲一點(diǎn)點(diǎn)性能，是有必要的。
最后，解決問(wèn)題很簡(jiǎn)單。既然delegateQueue不安全，那么就傳nil進(jìn)去吧，或者搞一個(gè)靜態(tài)的dispatch_queue；delegate問(wèn)題可以修改代碼邏輯，在停止播放的時(shí)候清掉這個(gè)回調(diào)，這樣保證當(dāng)self釋放時(shí)，videoOutpu的delegate已經(jīng)是nil了。
