从一个crash分析到苹果的代码问题

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