main.m 中的 EXC_BAD_ACCESS答案

【问题标题】：EXC_BAD_ACCESS in main.mmain.m 中的 EXC_BAD_ACCESS
【发布时间】：2011-09-15 01:14:00
【问题描述】：

突然我在这一行得到了 EXC_BAD_ACCESS：

int retVal = UIApplicationMain(argc, argv, nil, nil);

代码如下：

int main(int argc, char *argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    int retVal = UIApplicationMain(argc, argv, nil, nil);
    [pool release];
    return retVal;
}

我什至不知道从哪里开始寻找？

有人可以帮忙吗？

【问题讨论】：

标签： iphone objective-c exc-bad-access

【解决方案1】：

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

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

当调试器有时会发现任何有用的信息时，它尤其有助于后台线程。

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

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

【讨论】：

现在最好的方法是在 Instruments 中使用 Zombies 模板。它向您显示比调试器更多的信息：即僵尸（或任何其他）对象的整个历史记录。
关于 NSZombieEnabled 的死链接 :(

【解决方案2】：

EXC_BAD_ACCESS 是一个信号，表明您正在尝试访问内存中已释放或不存在的变量。由于它是在您的自动释放池释放后显示的，这意味着您可能过度释放了一个带有待处理自动释放的变量，因此当自动释放池耗尽时该变量不再存在以释放。

有很多现有的问题可以解决这个问题，其中最重要的是this one。

【讨论】：

【解决方案3】：

EXC_BAD_ACCESS 通常表明您已过度释放内存。您可以使用 Xcode 中的“构建和分析”命令来帮助追踪它。我还建议在整个代码中放置断点和日志记录语句以隔离错误。

【讨论】：

【解决方案4】：

我遇到了这个问题，可能是因为您使用的是 Apple 最新的 main.m：

NSString * appDelegateClassName;

@autoreleasepool {
    // Setup code that might create autoreleased objects goes here.
    appDelegateClassName = NSStringFromClass([AppDelegate class]); }

return UIApplicationMain(argc, argv, nil, appDelegateClassName);

我不使用ARC，我将其更改为他们曾经使用的代码：

@autoreleasepool
{
    return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}

这似乎行得通！

【讨论】：