NSZombieEnabled完全隐藏EXC_BAD_ACCESS错误 [英] NSZombieEnabled hides EXC_BAD_ACCESS error entirely

问题描述

所以我有一个UIView的子类，当我经历一系列特定的条件时（在iPad而不是iPhone或模拟器上运行，仅首次登录），它会开始导致EXC_BAD_ACCESS错误。当UIView子类从池中自动释放时（即当我正在调用[view autorelease]时，在最后一行，我有[super dealloc]），它会抛出异常。我听说过使用NSZombieEnabled，所以我把它扔了，看看我是否可以获得更多关于它的信息，但现在它完全隐藏了错误！

So I have a subclass of a UIView that starts causing EXC_BAD_ACCESS errors when I go through a specific set of conditions (run on iPad instead of iPhone or simulator, first login only). It throws the exception when the UIView subclass gets autoreleased from the pool (i.e. the pool is releasing, not when I'm calling [view autorelease], during the last line, where I have [super dealloc]. I heard about using NSZombieEnabled, so I tossed that on to see if I could get any more information about it, but now it hides the error completely!

有没有人对这种类型的更多了解情况？我以为NSZombie会像以前一样开始向我的控制台喷出东西，但我希望错误的不存在也会告诉我一些信息。

Does anyone know a bit more about this type of situation? I thought NSZombie would start spewing stuff into my console like before, but I'm hoping that the nonexistance of errors would tell me some sort of information as well.

- (void)dealloc  
{  
    [loadingLabel release];  
    [indicatorView release];  
    [super dealloc];  
} 

编辑：好的，所以我解决了根本问题：

Ok, so I sorta solved the underlying problem:

我的一个属性是：

@property（nonatomic，retain）NSString * title;

然而，代码f或者该属性如下（loadingLabel是UILabel）：

However, the code for that property is as follows (loadingLabel is a UILabel):

- (void)setTitle:(NSString *)title
{
    loadingLabel.text = title;
    [loadingLabel sizeToFit];
    [self setNeedsLayout];
}

- (NSString *)title
{
    return loadingLabel.text;
}

我实际上并没有保留任何东西，而只是做一个UILabel.text ，这是一个复制属性。所以我改变了我自己的title属性以反映这一点，并且错误已经消失。

I don't actually retain anything, but rather only do a UILabel.text, which is a copy property. So I changed my own title property to reflect this, and the error has disappeared.

但是，我仍然不知道这个错误是如何或为什么会出现在第一名，以及为什么它只出现在iPad平台上（不是iphone，甚至是ipad模拟器）。

However, I still don't really know how or why this error popped up in the first place, and why it only appears on the iPad platform (not the iphone, or even the ipad simulator).

推荐答案

所以我有一个UIView的子类，当我经历一系列特定条件时（在iPad而不是iPhone或模拟器上运行，仅首次登录），它会开始导致EXC_BAD_ACCESS错误。当UIView子类从池中自动释放时（即当我正在调用[view autorelease]时，在最后一行，我有[super dealloc]），它会抛出异常。我听说过使用NSZombieEnabled，所以我把它扔了，看看我是否能得到更多关于它的信息，但现在它完全隐藏了错误！

So I have a subclass of a UIView that starts causing EXC_BAD_ACCESS errors when I go through a specific set of conditions (run on iPad instead of iPhone or simulator, first login only). It throws the exception when the UIView subclass gets autoreleased from the pool (i.e. the pool is releasing, not when I'm calling [view autorelease], during the last line, where I have [super dealloc]. I heard about using NSZombieEnabled, so I tossed that on to see if I could get any more information about it, but now it hides the error completely!

你得到的EXC_BAD_ACCESS，因为你试图使用一个死对象。

You get EXC_BAD_ACCESS because you tried to work with a dead object.

NSZombieEnabled使对象不会死。由于对象永远不会死，你的应用程序没有崩溃。相反，你会在控制台日志中获取一条消息（在Xcode下运行时调试控制台），告诉你你做错了什么并建议设置一个断点。

NSZombieEnabled makes objects not die. Since the object never died, your app didn't crash. Instead, you'll get a message in the Console log (the Debugger Console when running under Xcode), telling you what you did wrong and suggesting a breakpoint to set.

更具体一点， NSZombie消息将告诉您发送消息的对象类以及发送消息的消息。如果设置断点并在调试器处于活动状态时运行应用程序，调试器将中断（中断）您在那个时候的应用程序，这样你就可以环顾四周，看看 发送了僵尸对象的消息。

To be more specific, the NSZombie message will tell you what class of object you sent a message to, and what message you sent it. If you set the breakpoint and run your app with the debugger active, the debugger will interrupt ("break") your app at that point, so that you can look around and see what sent the zombie object the message.

我实际上没有保留任何东西，而只是[分配给] UILabel.text，这是一个复制属性。

I don't actually retain anything, but rather only [assign to] a UILabel.text, which is a copy property.

因此，字符串可能因为不归任何东西而死亡。使用NSZombieEnabled和上述技术，你可以确认它是过早死亡的字符串理论。

Thus, the string presumably died off for not being owned by anything. With NSZombieEnabled and the above technique, you can confirm the theory that it was the string that was dying off prematurely.

然而，更好更简单的方法是使用Instruments的僵尸模板。而不是出现在Xcode的调试器控制台中的消息，标志将显示仪器的时间轴和信息。该标志将有一个go-to-iTunes-Store（➲）按钮，您可以单击该按钮以获取有关该问题的更多信息。

A better and easier way, though, is to use Instruments's Zombies template. Instead of a message appearing in Xcode's Debugger Console, a flag in will appear Instruments's timeline with the information. That flag will have a go-to-iTunes-Store (➲) button you can click for more information about the problem.

这篇关于NSZombieEnabled完全隐藏EXC_BAD_ACCESS错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！