汇编定位 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 + 28546240x0000000100060000 是项目的基地址，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崩溃异常