NSZombieEnabled 不报告导致 EXC_BAD_ACCESS 错误的对象类型答案

【问题标题】：NSZombieEnabled doesn't report the type of object causing an EXC_BAD_ACCESS errorNSZombieEnabled 不报告导致 EXC_BAD_ACCESS 错误的对象类型
【发布时间】：2009-10-27 18:32:43
【问题描述】：

由于某种原因，我在 UIKit 深处发生了崩溃； EXC_BAD_ACCESS 错误正在发生，例如 8 次调用深入到dismissModalViewController 调用中。我尝试为我的可执行文件启用 NSZombieEnabled，但无论僵尸是否打开，控制台日志都会打印相同的错误，而且我不知道是哪个对象导致了问题。我需要做些什么来让控制台打印正确的信息吗？

【问题讨论】：

我们真的需要查看这个堆栈跟踪。要么你在 dealloc 中释放了已经被释放的东西，要么你正在调用正在使用已经被释放的东西的东西，或者其他东西可能在它被解除后试图回调到被解除的模式视图。

标签： iphone objective-c cocoa uikit zombie-process

【解决方案1】：

了解如何使用 Zombies here。

在 gdb 中运行它。当你得到EXC_BAD_ACCESS 时，查看堆栈（使用 gdb 的 where 命令或运行 Xcode GUI 调试器）。如果您仍有问题，请将堆栈发布到您的原始问题中。

此外，只有在处理 NSObjects 时，僵尸才会对您有所帮助。如果您使用低级别的 malloc/free 例程，僵尸不会为这些分配购买任何东西。

【讨论】：

你最后的陈述可能是这样的。核心动画代码中的一些问题导致崩溃，因为应用程序中的一些先前操作会阻止任何动画的发生；幸运的是，一些有根据的猜测让我解决了这个问题。
@nall 帖子中名为“here”的链接指向一个一直存在的 CocoaDev 页面。这在 UNIX 世界中并不一定是坏事，但要厌倦复制 AdhamhFindlay 如此周到地提供的 ~/.gdbinit 设置。我在 Xcode 2.2 附近的某个地方这样做了，当时它们似乎没有造成任何伤害，而且几乎没有什么好处，但我已经删除了它们。如果您觉得需要更改任何 gdb 设置，请使用 Xcode 的 Target Info >> Build settings 来执行此操作。就 NSZombieEnabled 而言，在我看来，它通常与它命名的生物一样有用。
不使用 .gdbinit 的理由是什么？仅将设置放在 Xcode 中会阻止 gdb 在 Xcode 之外运行时尊重这些设置（我碰巧经常这样做）

【解决方案2】：

我在上周末 NSZombieEnabled 似乎根本不起作用时学到的一件事 - 确保您没有将非对象传递给某些代码。

在我的例子中，我返回的 NSString 只是“字符串”而不是 @“字符串”。这意味着我正在用 c-string 覆盖一个 NSString 对象。当我后来尝试在该对象中写入一个新值时，我得到了一个 BAD_ACCESS。 NSZombie 忍不住 b/c 它不是我试图覆盖的对象，而是那个 c 字符串。

顺便说一句，在 XCode 中将所有警告视为错误 - 希望我能让它们在 IDE GUI 中以 RED 显示 - 它们有时很容易被忽略。

【讨论】：

让它们显示在 RED 中的下一个最佳方法是检查目标信息的构建部分中的“将警告视为错误”。

【解决方案3】：

听起来像是在您的模态视图控制器中过度释放了某些东西。首先注释掉新行，直到它停止中断。

【讨论】：

我知道，但这并不能回答为什么 NSZombieEnabled 不能像宣传的那样工作，这会使调试变得更加简单。
随机注释掉“新”行是一种非常低效的调试方式。
也许对你来说，但对于我编写代码的方式（少即是多），它是相当有效的。
无论编码风格如何，崩溃最好在调试器中进行调试。不是通过猜测可能导致问题的原因。
是的……对不起，你错了。在调试器没有任何有用的知识的情况下，这种方式非常有效。如果他只是在他的某个地方发生了崩溃，并且他在控制器中添加了几件事，直到他注意到它坏了，那么注释掉这几行并不是很困难。当 NSZombieEnabled 没有提供任何有用的信息时，追踪这些是一件很痛苦的事情。通过代码检查/注释我上次所做的事情，我每次都在不到 5 分钟的时间内找到它们。