ios leaks afnetworking3.0多处内存泄露怎么回事

发布网友发布时间：2022-05-03 20:09

共2个回答

懂视网时间：2022-05-04 00:31

我们做iOS 程序开发时经常用遇到 EXC_BAD_ACCESS 错误导致 Crash，出现这种错误时一般 Xcode 不会给我们太多的信息来定位错误来源，只是在应用 Delegate 上留下像 Thread 1: Program received signal:EXC_BAD_ACCESS ，让问题无从找起。比如你对已释放的对

我们做iOS 程序开发时经常用遇到 EXC_BAD_ACCESS 错误导致 Crash，出现这种错误时一般 Xcode 不会给我们太多的信息来定位错误来源，只是在应用 Delegate 上留下像Thread 1: Program received signal:"EXC_BAD_ACCESS"，让问题无从找起。

比如你对已释放的对象发送消息时就会出现，EXC_BAD_ACCESS，再如release 的对象再 release，release 那些autorelease 的对象等也会报这样的错。默认设置下 Xcode 不会给你定位具体是哪一行代码，不该去使用已释放的对象，或者release 用错了。

比如 UIViewController 子类中这样的代码：

[cpp] view plaincopyprint?

static NSMutableArray*array;
-(void)viewDidLoad
{
[superviewDidLoad];
array= [[NSMutableArray alloc]initWithCapacity:5];
[array release];//释放掉该数组
}
- (void)viewWillAppear:(BOOL)animated{
[array addObject:@"Hello"];//使用释放掉的数组
}

上面的代码就会出现EXC_BAD_ACCESS 错误，但我执行时 Xcode 一出错却是定位在我在 AppDelegate 的 application:didFinishLaunchingWithOptions: 方法上的某行了，如果代码量多了，要查找具体问题非常难，但凭经验了。

不过NSZombieEnabled 环境变量可以帮我们的忙，就是当设置NSZombieEnabled环境变量后，一个对象销毁时会被转化为_NSZombie，设置NSZombieEnabled后，当你向一个已经释放的对象发送消息，这个对象就不会向之前那样Crash或者产生一个难以理解的行为，而是放出一个错误消息，然后以一种可预测的可以产生debug断点的方式消失，因此我们就可以找到具体或者大概是哪个对象被错误的释放了。

对 Xcode 设置了NSZombieEnabled 之后，Xcode 会明确定位在行[array addObject:@"Hello"]，然后控制台下报的错误信息是：

*** -[__NSArray addObject:]:message sent to deallocated instance 0x6557370

如何设置 NSZombieEnabled 呢，在 Xcode3 和 Xcode4 下设置不一样，Xcode4 下设置很简单。
Xcode3 下 NSZombieEnabled 设置方法如下：

1. 在XCode左边那个Groups& Files栏中找到Executables，双击其中的一项，或者右键Get Info；
2. 切换到Arguments
3. 这里一共有两个框，在下面那个Variables to be set in theenvironment:点+号添加一项，Name里填NSZombieEnabled，Value填Yes，要保证前面的钩是选中的。

Xcode4 下设置 NSZombieEnabled 的方法：

你可以点击 Xcode4 菜单 Product -> Edit Scheme-> Arguments, 然后将点击”加号”, 将 NSZombieEnabled 参数加到Environment Variables 窗口中, 后面的数值写上 ”YES”.

或者在 Xcode4 菜单 Product -> EditScheme -> Diagnostics 设置窗口中直接勾上Enable ZombieObjects 即可，Xcode 可用 cmd＋shift＋< 进到这个窗口。

Xcode4 已经考虑到了现在的要求，所以提供了更便捷的设置的方式，你也可以在这个窗口中设置其他一些参数，你肯定能由此获得更多的帮助信息。

另外再说一下，如果没有为 Xcode 设置 NSZombieEnable，像下面的代码或许可以正确执行，打印出你所期望的结果“Hello”

[cpp] view plaincopyprint?

static NSMutableArray*array;
-(void)viewDidLoad
{
[super viewDidLoad];
array= [[NSMutableArray alloc]initWithCapacity:5];
[array release];
[array addObject:@"Hello"];//之所以不会crash，是在于事件周期未完，内存回收机制还没有执行，没有真正的回收掉array的对象内存。
NSLog(@"%@",[array objectAtIndex:0]);
}

但是一旦加上了NSZombieEnable 设置，上面的代码行 [array addObject:@"Hello"] 也将无法投机取巧了，同样会得到错误提示：

*** -[__NSArrayM addObject:]:message sent to deallocated instance 0x6557370

即使该array 所指向的内存还是原来的数据也不能逃脱掉 NSZombieEnable 的法眼。也就是之所以未设置 NSZombieEnable 时上面代码能得到正确结果，是因为，虽然 [array release] 是标记为释放掉该内存块，但是后面使用 array 时，因为该指针指向的内存数据未被覆盖，所以未出错，这和C++ 的指针 delete 后的效果是一样的。

CocoaDev，个人觉得讲Cocoa技术十分专业的网站之一，下面的链接详细讲了讲NSZombieEnable的原理。http://www.cocoadev.com/index.pl?NSZombieEnabled
苹果官方的Mac OS X Debugging Magic,详细讲述了最为一个高级苹果程序员应该具备的调试技巧 http://developer.apple.com/library/mac/#technotes/tn2004/tn2124.html
其实还可以在Instruments中开启NSZombie选项，这样就可以在Instruments中直接查看crash时候的callstack了：http://www.markj.net/iphone-memory-debug-nszombie/

最后提醒NSZombieEnabled只能在调试的时候使用，千万不要忘记在产品发布的时候去掉，因为NSZombieEnabled不会真正去释放dealloc对象的内存，一直开启后果可想而知，自重！

http://unmi.cc/nszombieenabled-locate-exc_bad_access-error,来自隔叶黄莺 Unmi Blog

热心网友时间：2022-05-03 21:39

1、运行Demo。
先下载一个实现准备好的内存泄露的Demo吧：leak app
下载下来，打开运行，程序是一个寿司的列表，列出各种寿司卷。试着选择里面的几行，应该是选第二行的时候就崩溃了。崩溃截图：

在崩溃的地方断住了，知道crash的地方了，但是不知道具体crash的原因。

2、设置NSZombieEnabled
这是一个 “EXC_BAD_ACCESS”错误。我们打开XCode的选项：“NSZombieEnabled” 。在crash时可能会给你更多的一些提示信息。
设置步骤：1

2：勾上红色框里的

运行，按刚才的操作选中其中的cell。再次crash，这次在output窗口会看到多了一项错误信息：

2012-11-28 13:22:08.911 PropMemFun[2132:11303] *** -[CFString respondsToSelector:]: message sent to deallocated instance 0x713ebc0
大概意思是：向已释放的内存发送消息。也就是说使用了已释放的内存，在C语言相当于使用了“野指针”

看了下crash的这个语句，sushiString应该是没问题的，它是从stringWithFormat初始化出来的。那就是_lastSushiSelected的问题。
_lastSushiSelected指向了sushiString，sushiString是一个autorelease变量。在第二次点击时，使用的是sushiString已经被释放，所以crash了。那为_lastSushiSelected保留一下，就可以用了。代码修改如下：

[cpp] view plaincopy
 _lastSushiSelected = [sushiString retain];

[cpp] view plain copy
 _lastSushiSelected = [sushiString retain];

运行，这时候不崩溃。

3、分析内存泄露(shift+command+b)
app不crash了，那看看有没有内存泄露。用XCode的Analyze就能分析到哪里有内存泄露

分析之后可以看到：

这里提示alertView没被释放，有内存泄露，那我们释放
[alertView release];
再分析，这个问题解决了。

4、使用Instruments的leaks工具
分析内存泄露不能把所有的内存泄露查出来，有的内存泄露是在运行时，用户操作时才产生的。那就需要用到Instruments了。

按上面操作，build成功后跳出Instruments工具，选择Leaks选项，这时候寿司程序也运行起来了，选中list中的项，拖动等操作后，工具显示效果如下：

大家可能都能猜到，红色的柱子表示内存泄露了。怎么通过这个工具看到在哪泄露了呢?
先在工具栏按下红色的圆形按钮，把工具监视内存的活动停下来。选择Leak，然后点中间十字交叉那，选择Call Tree.
这时候左下角的Call Tree的可选项可以选了。选中Invert Call Tree 和Hide System Libraries,显示如下：

这时候内存泄露的具体代码找到了，在右边的红色框框里指定了哪个方法出现了内存泄露。
你只要在这些方法上双击，就会跳转到具体的代码，哈哈，是不是很方便。

这里应该是提示100%内存会泄露。
6、解决内存泄露问题
问题找到了，那就解决吧
关于：tableView:didSelectRowAtIndexPath ，分析下它的内存过程：
sushiString变量通过autorelease创建，它的引用计数是1.
这行代码使得引用计数增加到2， _lastSushiSelected = [sushiString retain];
这个方法结束时，sushiString的autorelease生效了，这个变量的引用计数减少为1
当再次执行tableView:didSelectRowAtIndexPath这个方法时，_lastSushiSelected被赋值了新指针，老的_lastSushiSelected的引用计数还是1，没有被释放，产生了内存泄露。
怎么解决呢?
在_lastSushiSelected = [sushiString retain];之前把原来的release就ok了:

[cpp] view plaincopy
 [_lastSushiSelected release];
_lastSushiSelected = [sushiString retain];
[cpp] view plain copy
 [_lastSushiSelected release];
_lastSushiSelected = [sushiString retain];
关于：tableView:cellForRowAtIndexPath
这个比较明显，sushiString被alloc和init之后就没有释放，可以用stringWithFormat来调用autorelease，代码如下：

[cpp] view plaincopy
NSString *sushiString = [NSString stringWithFormat:@"%d: %@", indexPath.row, sushiName];
[cpp] view plain copy
NSString *sushiString = [NSString stringWithFormat:@"%d: %@", indexPath.row, sushiName];
好了，泄露都fix了，再用工具分析看看，这时候你再点，再拖，再怎么操作，都没有内存泄露了。表明内存泄露被堵住了。