在 Xcode 中中断 EXC_BAD_ACCESS? [英] Break on EXC_BAD_ACCESS in Xcode?

查看:21
本文介绍了在 Xcode 中中断 EXC_BAD_ACCESS?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我是 iPhone 开发和 Xcode 的新手,不知道如何开始对 EXC_BAD_ACCESS 信号进行故障排除.如何让 Xcode 在导致错误的确切行处中断?

I'm new to iPhone development and Xcode in general and have no idea how to begin troubleshooting an EXC_BAD_ACCESS signal. How can I get Xcode to break at the exact line that is causing the error?

我似乎无法让 Xcode 在导致问题的线路上停止,但我确实在调试控制台中看到以下几行:

I can't seem to get Xcode to stop on the line causing the problem, but I do see the following lines in my debug console:

10 月 25 日星期日 15:12:14 jasonsmacbook测试项目[1289]:CGContextSetStrokeColorWithColor:上下文无效

Sun Oct 25 15:12:14 jasonsmacbook TestProject[1289] : CGContextSetStrokeColorWithColor: invalid context

10 月 25 日星期日 15:12:14 jasonsmacbook测试项目[1289]:CGContextSetLineWidth: 无效的上下文

Sun Oct 25 15:12:14 jasonsmacbook TestProject[1289] : CGContextSetLineWidth: invalid context

10 月 25 日星期日 15:12:14 jasonsmacbook测试项目[1289]:CGContextAddPath: 无效的上下文

Sun Oct 25 15:12:14 jasonsmacbook TestProject[1289] : CGContextAddPath: invalid context

10 月 25 日星期日 15:12:14 jasonsmacbook测试项目[1289]:CGContextDrawPath: 无效的上下文

Sun Oct 25 15:12:14 jasonsmacbook TestProject[1289] : CGContextDrawPath: invalid context

2009-10-25 15:12:14.680LanderTest[1289:207] *** -[CFArrayobjectAtIndex:]: 消息发送到解除分配的实例 0x3c4e610

2009-10-25 15:12:14.680 LanderTest[1289:207] *** -[CFArray objectAtIndex:]: message sent to deallocated instance 0x3c4e610

现在,我试图绘制到我从 UIGraphicsGetCurrentContext() 检索到的上下文中,并传递给我想要绘制的对象.

Now, I am attempting to draw to the context I retrieve from UIGraphicsGetCurrentContext() and pass to the object that I want to draw with.

进一步的反复试验和错误调试,我发现我在我的班级上拥有一个属性的 NSMutableArray 是一个僵尸.我进入了该类的 init 函数,这是我使用的代码:

Further trial and error debugging and I found that an NSMutableArray I have a property for on my class was a zombie. I went into the init function for the class and here's the code I was using:

if ((self = [super init])) {
        NSMutableArray *array = [NSMutableArray array];
        self.terrainBlocks = array;
        [array release];
    }
    return self;    
}

我删除了 [array release] 行,它不再给我 EXC_BAD_ACCESS 信号,但我现在很困惑为什么会这样.我认为当我使用该属性时,它会自动为我保留它,因此我应该从 init 中释放它,这样我就不会泄漏.我对它是如何工作的感到非常困惑,我读过的所有指南和 Stackoverflow 问题都让我更加困惑如何在我的 init 方法中设置属性.关于哪种方式最好,似乎没有达成共识.

I removed the [array release] line and it no longer gives me the EXC_BAD_ACCESS signal, but I'm now confused about why this works. I thought that when I used the property, it automatically retained it for me, and thus I should release it from within init so that I don't have a leak. I'm thoroughly confused about how this works and all the guides and Stackoverflow questions I've read only confuse me more about how to set properties within my init method. There seems to be no consensus as to which way is the best.

推荐答案

对于任何 EXC_BAD_ACCESS 错误,您通常会尝试向已发布的对象发送消息.追踪这些的最佳方法是使用NSZombieEnabled.

For any EXC_BAD_ACCESS errors, you are usually trying to send a message to a released object. The BEST way to track these down is use NSZombieEnabled.

这是通过从不实际释放对象,而是通过将其包装为僵尸"并在其中设置一个标志来表示它通常会被释放.这样,如果您再次尝试访问它,它仍然会在您出错之前知道它是什么,有了这些信息,您通常可以回溯以查看问题所在.

This works by never actually releasing an object, but by wrapping it up as a "zombie" and setting a flag inside it that says it normally would have been released. This way, if you try to access it again, it still know what it was before you made the error, and with this little bit of information, you can usually backtrack to see what the issue was.

它在后台线程中特别有用,因为调试器有时会发现任何有用的信息.

It especially helps in background threads when the Debugger sometimes craps out on any useful information.

非常重要的注意事项 但是,您需要 100% 确保这仅在您的调试代码中,而不是在您的分发代码中.因为没有任何东西被发布,你的应用程序会泄漏,泄漏和泄漏.为了提醒我这样做,我把这个日志放在我的 appdelegate 中:

VERY IMPORTANT TO NOTE however, is that you need to 100% make sure this is only in your debug code and not your distribution code. Because nothing is ever released, your app will leak and leak and leak. To remind me to do this, I put this log in my appdelegate:

if(getenv("NSZombieEnabled") || getenv("NSAutoreleaseFreedObjectCheckEnabled"))
  NSLog(@"NSZombieEnabled/NSAutoreleaseFreedObjectCheckEnabled enabled!");

如果您需要帮助找到确切的行,请执行构建和调试 (CMD-Y) 而不是构建和运行 (CMD-R).当应用程序崩溃时,调试器会准确显示哪一行,并结合 NSZombieEnabled,您应该能够找出确切原因.

If you need help finding the exact line, Do a Build-and-Debug (CMD-Y) instead of a Build-and-Run (CMD-R). When the app crashes, the debugger will show you exactly which line and in combination with NSZombieEnabled, you should be able to find out exactly why.

这篇关于在 Xcode 中中断 EXC_BAD_ACCESS?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆