XCode调试技巧之EXC_BAD_ACCESS中BUG解决

XCode调试技巧之EXC_BAD_ACCESS中BUG解决是本文要介绍的内容，在iphone开发的时候EXC_BAD_ACCESS这个bug时不容易找到原因的，在网上找到的3个关于这个问题的方法，希望可以帮到你，我自己试了一下第二种方法，效果还不错

首先说一下 EXC_BAD_ACCESS 这个错误，可以这么说，90%的错误来源在于对一个已经释放的对象进行release操作。

一. 通过NSZombieEnabled

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

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

• NSString* hello = [NSString stringWithFormat:@"Hello world"];
• NSLog(@"What you say is %@",hello);
• [hello release];
  

运行后出现EXC_BAD_ACCESS错误.但没有其他任何提示,这时 候

product -> scheme->edit scheme

,在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,因为它们会使得内存不会被释放.

二. 重写object的respondsToSelector方法

重写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的方法。

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

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

小结：XCode调试技巧之EXC_BAD_ACCESS中BUG解决的内容介绍完了，希望本文对你有所帮助！