在 Objective-C 编程中遇到 EXC_BAD_ACCESS 问题的时候，通过简单常规的手段很难发现问题。
首先说一下 EXC_BAD_ACCESS 这个错误，可以这么说，90%的错误来源在于对一个已经释放的对象进行release操作。
给大家介绍一个常用的查找 EXC_BAD_ACCESS 问题根源的方法。
MRC下示例代码
#import <Foundation/Foundation.h>
int main (int argc, c*****t char * argv[])
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
NSString* s = [[NSString alloc]initWithString:@”This is a test string”];
s = [s substringFromIndex:[s rangeOfString:@"a"].location];//内存泄露
[s release];//错误释放 [pool drain];//EXC_BAD_ACCESS return 0;
}
这个例子当然狠容易的看出问题所在，如果这段代码包含在一个很大的逻辑中，确实容易被忽略。Objective-C 这段代码有三个致命问题：1，内存泄露。2，错误释放。3，造成 EXC_BAD_ACCESS 错误。
1，内存泄露。 NSString* s = [[NSString alloc]initWithString:@”This is a test string”]; 创建了一个 NSString Object， 随后的 s = [s substringFromIndex:[s rangeOfString:@"a"].location]; 执行后，导致创建的对象引用消失，直接造成内存泄露。
2，错误释放。[s release]; 这个问题，原因之一是一个逻辑错误，以为 s 还是我们最初创建的那个 NSString 对象。 第二是因为从 substringFromIndex:(NSUInteger i) 这个方法返回的 NSString 对象，并不需要我们来释放， 它其实是一个被 substringFromIndex 方法标记为 autorelease 的对象。如果我们强行的释放了它，那么会造成 EXC_BAD_ACCESS 问题。
3，造成 EXC_BAD_ACCESS 错误。EXC_BAD_ACCESS。由于 s 指向的 NSString 对象被标记为 autorelease, 则在 NSAutoreleasePool 中已有记录。但是由于我们在前面错误的释放了该对象，则当 [pool drain] 的时候，NSAutoreleasePool 又一次的对它记录的 s 对象调用了 release 方法，但这个时候 s 已经被释放不复存在，则 直接导致了 EXC_BAD_ACCESS问题。
Enable NSZombie Objects(开启僵尸对象 )
开启Zombie模式之后会导致内存上升，因为所以已经被释放（引用计数为0）的对象被僵尸对象取代，并未真的释放掉。
这个时候再给僵尸对象发送消息，就会抛出异常，并打印出异常信息，你可以轻松的找到错误代码位置，结束Zombies时会释放。它的主要功能是检测野指针调用。
具体这样做：
再试试输出Object的信息
注意：Zombie模式不能再真机上使用，只能在模拟器上使用, 只能用在模拟器和OC语言。
Address Sanitizer（地址消毒剂）
在Xcode7之后新增了AddressSanitizer工具，为我们调试EXC_BAD_ACCESS错误提供了便利。
当程序创建变量分配一段内存时，将此内存后面的一段内存也冻结住，标识为中毒内存。程序访问到中毒内存时（访问越界），立即中断程序，抛出异常并打印异常信息。
你可以根据中断位置及输出的Log信息来解决错误。当然，如果变量已经释放了，它所占用的内存也会被标识为中毒内存，这个时候访问这片内存空间同样会抛出异常。
开启AddressSanitizer之后，在调试程序的过程中，如果有遇到EXC_BAD_ACCESS错误，程序则会自动终端，抛出异常。
