一、背景简介
在项目中我们经常会遇到这种以下这种坏内存访问问题，意思是访问了一块不存在的内存就会报以上的经典错误，关键是这经典错误很少会报其他的错误信息，就直接是如下截图那样报一个错，很少在控制器上打印信息。另外还有一个特点，这个报错不会在某一行代码结束了就报错，而是在之后的某一个时间段再报错，也有可能压根就不报错，所以这个就很尴尬了...
那么面对这种问题该如何解决呢？
二、问题分析
1>首先有人会说全局断点，这个可以试试，但是不太管用，像这种坏内存访问的问题很难通过断点定位出来，所以这个还是先放屁吧，可以作为第一个排查手段，以下附几张全局断点的打法截图：
出现以下这个All Exceptions就对了
2>开启僵尸对象检测，这个也有人提说这个开启之后能提供一些信息，这个要看场景，我的出现的那个坏内存访问问题不是通过这个解：
3>开启内存分析，我就是通过这个来检测到的，尤其是对于MRC和OC与C之间的内存转换的时候，这个能起很大帮助，以下是开启内存分析的截图：
当然还有一种快捷方式：command+shift+B
三、问题解决
在我的项目中通过开启内存分析，开启之后会出现蓝色的标记，说明这个位置是有内存相关问题存在的需要解决，不然很有可能引发内存泄露问题或者其他问题。开启之后，查到了相关的内存问题，其中主要是由于我在外部定义了一个dispatch_semaphore_t semaphore这个信号量，但是在block中使用了被block捕获，未使用__block来修饰导致的问题，具体问题如下：
__block dispatch_semaphore_t semaphore;
四、文末扩展
1>针对于内存问题是有很多内容的，我这只是冰山一角，还有内存循环引用问题等。此处主要针对于MRC环境下大家遇到内存问题可以用以上方式去尝试解决，即便可能没有遇到问题也可以通过此方式来降低crash的风险
2>针对于第三点中提到的信号量的问题，这个主要的用处是可以等待异步的请求结束，相当于将异步通过此方式达到同步的效果，具体的效果还得通过代码才能有此效果，特别是同个页面的多个AFN请求，每个AFN请求都是依赖于上一个AFN请求结果之后再去请求，那么信号量的作用就很大了,具体可以看下AFN请求依赖。
以上！！！
