先看一下收到的crash堆棧
objc_retain
完全是系統函數，不能簡單的從自身代碼找問題。
先看一下錯誤原因，SEGV_ACCERR是內存訪問失敗的錯誤，一般是對象被釋放的情況比較多。不過這個堆棧全部是系統函數，比較難判斷是那個對象被釋放了。
堆棧里唯一比較眼熟的是 -[AVPlayerItemVideoOutput _dispatchOutputMediaDataWillChange] , 所以我們看一下這個方法的匯編代碼
(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行有一個很關鍵的提示
symbol stub for: __46-[AVCaptureMetadataOutput _updateRemoteQueue:]_block_invoke
根據名字可以發現，應該是在block里調用了 _updateRemoteQueue: 方法，_updateRemoteQueue: 在調用dispatch_async時出錯，很可能是queue被釋放了。
項目里代碼用到AVPlayerItemVideoOutput是這樣寫的
_myVideoOutputQueue = dispatch_queue_create("myVideoOutputQueue", DISPATCH_QUEUE_SERIAL);
[_videoOutput setDelegate:self queue:_myVideoOutputQueue];
在釋放的時候直接這樣寫的
[_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;
看到這里心里大概就有數了，delegateQueue被聲明為nonatomic，當對象被釋放時，另一個線程訪問就可能出現問題。
為什么nonatomic會有線程安全問題？這要看一下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取到函數地址后，直接返回指針指向的值，如果這時 *slot 正好被釋放，那么返回的就是一個錯誤的值；而atomic會先retain，然后放到自動釋放池，這樣就能保證返回的對象一定不會被釋放。
這里正好想到前幾天另一個出現概率很大的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
看上去是在一個gcd的block里，調用了respondsToSelector:，很顯然是一個delegate。項目里所有的delegate都是weak聲明的，理論上不會出現指針懸空的問題，直到我看到了這一行
@interface AVPlayerItemVideoOutput : AVPlayerItemOutput
/*!
@property delegate
@abstract The receiver's delegate.
*/
@property (nonatomic, readonly, assign, nullable) id<AVPlayerItemOutputPullDelegate> delegate;
@end
delegate的這種錯誤是很多年前才會有的，沒想到這竟然出自官方代碼。
UIKit的屬性都是聲明為nonatomic，因為都是在主線程調用，所以不加鎖其實是可以接受的，但是音視頻很多都是在非主線程操作的，為了安全犧牲一點點性能，是有必要的。
最后，解決問題很簡單。既然delegateQueue不安全，那么就傳nil進去吧，或者搞一個靜態的dispatch_queue；delegate問題可以修改代碼邏輯，在停止播放的時候清掉這個回調，這樣保證當self釋放時，videoOutpu的delegate已經是nil了。
