汇编定位 objc_msgSend + 16 出错的问题

前言：

本文涉及到汇编的部分基础，对汇编不懂的同学可以先看看iOS汇编入门-arm64基础这篇文章。

先看下出错堆栈

#0 Thread

SIGSEGV

SEGV_ACCERR

0 libobjc.A.dylib	0x000000018de86f30 objc_msgSend + 16
1 HLLCourseLive	    0x0000000100318ee0 0x0000000100060000 + 2854624
2 AVFAudio	        0x00000001a843d2a8 0x00000001a8422000 + 111272
3 Foundation	    0x000000018ff226ec 0x000000018fe18000 + 1091308
4 CoreFoundation	0x000000018f3ea278 0x000000018f30d000 + 905848
5 CoreFoundation	0x000000018f3e9b50 0x000000018f30d000 + 904016
6 CoreFoundation	0x000000018f3e77c0 0x000000018f30d000 + 894912
7 CoreFoundation	0x000000018f316048 CFRunLoopRunSpecific + 444
8 GraphicsServices	0x0000000190d99198 GSEventRunModal + 180
9 UIKit	            0x00000001952e9628 0x000000019526e000 + 505384
10 UIKit	        0x00000001952e4360 UIApplicationMain + 208
11 HLLCourseLive	0x00000001004397e0 0x0000000100060000 + 4036576
12 libdyld.dylib	0x000000018e2f85b8 0x000000018e2f4000 + 17848

其中有关项目的崩溃信息是第二行，在执行了第二行的方法后，在objc_msgSend + 16 的地方出现了 SEGV_ACCERR 的错误。

由于这里没有解析出来，所以需要我们自己去解析，一般的解析方法是利用 dsym 文件去解析。这里使用的是 Hopper 这个软件去定位具体的行。

由于是线上的崩溃，在拿到 xxx.xcarchive 包之后，把包里面的二进制文件拖进 hopper ，选择 Arm64 架构。

接下来我们就可以分析跳转到具体的崩溃位置了，刚好崩溃的线程有包含我们的项目代码，关注点自然就落在我们项目的崩溃行上

1 HLLCourseLive	    0x0000000100318ee0 0x0000000100060000 + 2854624

0x0000000100060000 是项目的基地址，2854624 是十进制的偏移量，而这个 0x0000000100318ee0 则是崩溃地址，刚好是 0x0000000100060000 + 2854624 的结果。

所以，我们下面要做的就是跳转到 0x0000000100318ee0 这个崩溃地址看看响应的汇编代码。

1. hopper -> Modify -> Change File Base Address... ，然后把基地址 0x0000000100060000 输入，重新 Rebase 一下。

2. hopper -> Navigate -> Go to Address or Symbol... ，输入 0x0000000100318ee0 这个地址，然后 go 到对应的崩溃地址。

可以看到是 move x29, x29 这个指令发生了崩溃了，往上看 imp_stubs_objc_msgSend 这句，刚好就是项目发生崩溃时候所调用的 objc_msgSend ，它的2个参数 x0 和 x1 可以看到分别来自 x19 和 x22 这2个寄存器，Hopper 很贴心的把 x22 代表的意义给写着后面的注释里了，可以看到就是 @selector(recordFileUrl) 这个方法。在往上看可以看到是[HLLRecordTool audioRecorderDidFinishRecording:successfully:] 这个方法，很明显，问题就出在了这个方法里面去调用 recordFileUrl 这个selector 的时候出现内存错误了。

看下实现代码：

#pragma mark - 录音结束
- (void)audioRecorderDidFinishRecording:(AVAudioRecorder *)recorder successfully:(BOOL)flag {
    [_recordingTimer invalidate];
    _recordingTimer = nil;
    
    _isRecording = NO;
    
    if (_isCancel) {
        if ([_delegate respondsToSelector:@selector(recordCancel:)]) {
            [_delegate recordCancel:self];
        }
        _isCancel = NO;
        return;
    }
    
    HLLRecordModel * recordingModel = [[HLLRecordModel alloc] init];
    recordingModel.path = self.recordFileUrl.path;
    recordingModel.fileName = [[self.recordFileUrl.path componentsSeparatedByString:@"/"] lastObject];
    recordingModel.recorderTimeInterval = _recordingTime;
    if ([_delegate respondsToSelector:@selector(record:didEndRecord:recordingModel:)]) {
        [_delegate record:self didEndRecord:flag recordingModel:recordingModel];
    }
}

函数进来第一个访问到 recordFileUrl 的便是 recordingModel.path = self.recordFileUrl.path; 这一句了。

结合项目，分析到这里大概可以知道原因了，在录音结束的时候回调到这个系统函数，然后在执行到 self.recordFileUrl 这里的时候 self 内存出现问题了导致了 SEGV_ACCERR 错误。那么接下来的目标就缩小成 self 是在什么时候被释放或者是变成无效内存的。

项目里查找有用到 RecordTool 这个类的地方

HLLRobotCheckMicrophView 这个类已经废弃，HLLRecordManager 是个单例，虽然持有 HLLRecordTool，但是项目运行期间不可能被释放，所以问题就落在了 HLLCheckDeviceMircrophView 这个类上面，一看是个View，有可能view被释放掉了然后 record 出问题了导致 SEGV_ACCERR。

再进一步分析，如果是 View 被释放掉了，然后属性 recordTool 也被释放掉了，按理来说不应该会回调到系统的 [HLLRecordTool audioRecorderDidFinishRecording:successfully:] 这个方法里面去，唯一的可能就是 View 被释放掉了，然后 recordTool 没有被释放，导致在View释放掉后，录音结束系统回调到 [HLLRecordTool audioRecorderDidFinishRecording:successfully:] 这个方法时在访问 self 的时候出现了无效的内存地址了。

 

接下来就是验证，在 HLLCheckDeviceMircrophView 和 HLLRecordTool 的 dealloc 方法里面分别加日志，发现View释放了，而 recordTool 确实没有被释放掉。

-(void)removeRecordCheck{
    //[self.recordTool stopRecord];
    self.recordTool.delegate = nil;
    self.recordTool = nil;
}

查看代码发现是在关闭 view 的时候没有做停止录音的操作，导致 AVAudioRecorder 强引用了 self 了，录音回调回来之后 self 又被释放掉了，导致崩溃。

 

知道了问题症结，接下来就比较好改了。

记录下改bug的过程主要是为了梳理，方便在以后遇到只有地址崩溃栈的时候也能从容面对。完结，撒花~

 

拓展阅读：

详解没有dSYM文件，如何解析iOS崩溃日志

低于0.01%的极致Crash率是怎么做到的？

手把手教你查看和分析iOS的crash崩溃异常