先看一下收到的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了。
网友评论