iOS开发过程中，普通的bug通常较容易定位问题所在，但是，EXD_BAD_ACCEEE问题却比较不易查找问题。本文记录下解决EXD_BAD_ACCEEE问题的过程。首先说一下 EXC_BAD_ACCESS 这个错误，可以这么说，90%的错误来源在于对一个已经释放的对象进行release操作。

1. 重写object的respondsToSelector方法，现实出现EXEC_BAD_ACCESS前访问的最后一个object

有时程序崩溃根本不知错误发生在什么地方。比如程序出现EXEC_BAD_ACCESS的时候，虽然大部分情况使用设定 NSZombieEnabled环境变量可以帮助你找到问题的所在，但少数情况下，即使设定了NSZombieEnabled环境变量，还是不知道程序崩 溃在什么地方。那么就需要使用下列代码进行帮助了：

 #ifdef _FOR_DEBUG_

-(BOOL) respondsToSelector:(SEL)aSelector {

    printf("SELECTOR: %s\n", [NSStringFromSelector(aSelector) UTF8String]);

    return [super respondsToSelector:aSelector];

}

#endif  

你需要在每个object的.m或者.mm文件中加入上面代码，并且在 other c flags中加入-D _FOR_DEBUG_（记住请只在Debug Configuration下加入此标记）。这样当你程序崩溃时，Xcode的console上就会准确地记录了最后运行的object的方法。

2. 通过NSZombieEnabled

相信很多人都知道通过NSZombies来帮助调试出现EXC_BAD_ACCESS的情况,但有时还是找不到需要的信息,那么应该怎么办呢?

下面通过一个例子来说明.下面是hello world的代码:

NSString* hello = [NSString stringWithFormat:@"Hello world"];

NSLog(@"What you say is %@",hello);

[hello release]; 

运行后出现EXC_BAD_ACCESS错误.但没有其他任何提示,这时 候通过右击executables下的应用程序名,选择get info后,在arguments下输入环境变量(NSZombieEnabled,MallocStackLogging)

再次运行后程序crash,如图：

这次可以看到问题是”message sent to dealloced object”了,但具体是哪个语句引起的还并不知道,于是需要在gdb上输入以下语句:

　　　　shell malloc_history pid address

那么pid和address是什么呢?再看下crash的图片结合一下我以下使用的命令,你应该很快就可以判定pid和address是从哪里来的了,我的命令是:

　　　　shell malloc_history 596 0×5f3ef80

再次运行,程序crash时会出现大量的stack trace信息,如下图是与本程序相关的:

根据这些信息大家就可以找到问题出现在[BadAccessViewController viewDidLoad] 中与 +[NSString stringWithFormat:] 有关的地方.

最后大家记得把环境变量NSZombieEnabled,MallocStackLogging删除或设置为NO,因为它们会使得内存不会被真实释放.

3、设置全局断点快速定位问题代码所在行

XCode调试技巧–设置全局断点快速定位问题代码所在行

注：转载  *