正如标题所说，我的应用程序在未启用垃圾收集时崩溃。该应用程序弹出几秒钟，然后它只是崩溃，除了调试器控制台中的这一点：
[Session started at 2009-08-17 15:03:20 -0600.]
GNU gdb 6.3.50-20050815 (Apple version gdb-966) (Tue Mar 10 02:43:13 UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin".sharedlibrary apply-load-rules all
Attaching to process 12535.
unable to read unknown load command 0x22
unable to read unknown load command 0x22
unable to read unknown load command 0x22
unable to read unknown load command 0x22
我不知道为什么会这样。我认为它可能是一个内存管理问题。我使用AnalysisTool（Clang Static Analyzer的前端）来检查泄漏和内存管理问题，并修复了它发现的问题。然而，通过Instruments运行应用程序会在启动时显示内存泄漏。我不知道这个漏洞来自哪里......启用垃圾收集后，应用程序运行正常，但是仪器仍然发现泄漏。
可根据要求提供源代码
由于
答案 0 :(得分：2)
XCode内置了一堆内存分析支持 - 将这些内容转换为可能会显示更多信息。我发现这些链接特别有用：
http://developer.apple.com/technotes/tn2004/tn2124.html#SECMALLOC
http://www.cocoadev.com/index.pl?NSZombieEnabled
答案 1 :(得分：2)
你可能不应该发布一个对象，然后发送一个后续消息。不幸的是，崩溃（发送后续消息的地方）不是问题所在 - 它是你释放（或更糟，解除分配）你不应该去的地方。 clang静态分析仪不是万无一失的，盲目遵循建议并不一定有帮助。
答案 2 :(得分：2)
由于错误说在解除分配的对象上调用[CFArray countByEnumeratingWithState:objects:count:]时会发生错误，因此可以很好地了解要查找的位置。该方法属于NSFastEnumeration的一部分，因此，除非您直接调用该方法（极不可能），否则会从数组中的 for (... in ...) 循环中调用它宾语。如果你可以找出它的位置，你可以在for循环上（或之前）设置一个断点，并检查你的对象是否已被释放。导致问题的最可能原因是无法正确保留数组，并且可能是由于运行循环耗尽了NSAutoReleasePool而发布的。
答案 3 :(得分：1)
如果在显示某些内容几秒钟后崩溃，则可能表示在运行循环结束时自动释放池释放了需要保留的内容。查看使用其他方法返回的对象分配变量的位置。在名称中没有“new”，“copy”，“alloc”（我认为还有其他几个）的任何方法通常表示如果你想继续使用它，你需要保留它。
这也可能意味着您已经发布了一些您不应该拥有的东西，并且它已经被自动释放池再次释放。查看释放对象的所有位置，并确保只释放自己保留的对象，或释放由显式声明所有权的方法返回的对象，例如“new”，“alloc”，“copy” “，”mutableCopy“等等。