【发布时间】:2012-02-06 21:51:23
【问题描述】:
我的 Mac 应用程序因运行循环上的 exc_bad_access 而崩溃。 所以我启用了 NSZombies,现在我没有看到预期的这样的错误(因为对象没有被释放)。
但是,我在控制台中找不到任何有用的 NSZombie Log。 有没有办法确定问题?
【问题讨论】:
标签: objective-c ios macos xcode4 nszombie
我的 Mac 应用程序因运行循环上的 exc_bad_access 而崩溃。 所以我启用了 NSZombies,现在我没有看到预期的这样的错误(因为对象没有被释放)。
但是,我在控制台中找不到任何有用的 NSZombie Log。 有没有办法确定问题?
【问题讨论】:
标签: objective-c ios macos xcode4 nszombie
这很有挑战性。 Cocoa 中此错误的最常见原因是直接访问您的 ivars 而不是使用访问器。访问器使绝大多数内存崩溃消失。
也就是说,它们并不是导致内存错误的唯一原因。您可能正在以其他方式访问内存。 NSZombie 做了一件特定的事情:当你释放一个对象时,NSZombie 说“实际上不要释放这个对象”。相反,它会将对象变成僵尸对象,如果您向其发送消息,则会打印错误。但这仅在崩溃是由于向释放的实例发送消息时才有帮助。可能还有很多其他的东西。
您应该首先从崩溃堆栈本身开始。查看堆栈,看看它可能是什么类型的对象,或者是谁在调用它。
阅读TN2124,尤其是关于BSD 内存分配器的部分,以及内存使用性能指南的Enabling the Malloc Debugging Features 部分。您可以使用比NSZombie 更低级别的工具。 MallocScribble 通常是最有用的。它用 0x55 覆盖释放的内存,这样您就更有可能更快地崩溃,并且更容易在调试器中检测释放的内存。 MallocPreScribble 对于查找未初始化的内存很有用,但这只有在您进行原始的 malloc 调用时才有帮助。 ObjC 对象总是预先初始化的。
当然,你必须戴上你的侦探帽。您的程序的哪些部分最可疑?你在做多线程工作吗(如果你没有正确锁定可能会导致内存崩溃)。
如果它很容易复制,那么你会弄明白的。如果它只是偶尔发生,那么……我有时会追捕这样的虫子好几个月了。有时候真的很难。
【讨论】:
您需要为此使用内存分析器。只需使用配置文件选项构建并选择泄漏。
【讨论】: