因此,我在对从测试人员那里获得的崩溃日志进行故障排除时遇到了一些困难。应用程序因 EXC_CRASH (SIGSEGV)
崩溃,任何线程中唯一可识别的代码位于线程 6 中。堆栈跟踪如下所示:
...
15 MyApplication 0x002cfcf2 0xfb000 + 1920242
16 MyApplication 0x00107f26 -[CCViewController dealloc] (CCViewController.m:73)
17 MyApplication 0x001cc27c -[CCSubmitReportController dealloc] (CCSubmitReportController.m:646)
18 CoreFoundation 0x36f41c3c 0x36f3f000 + 11324
...
26 Foundation 0x35396bd4 0x35387000 + 64468
27 MyApplication 0x001c794e -[CCGetFeedOperation main] (CCGetFeedOperation.m:102)
...
如果您查看 CCGetFeedOperation 中的第 102 行,您会发现它只是在工作结束时耗尽操作的自动释放池。
所以我试图弄清楚为什么自动释放池会尝试释放委托(delegate)。对委托(delegate)的引用将传递给操作类,如下所示:
@property (assign) id <CCGetFeedOperationDelegate> feedDelegate;
我唯一能想到的是,我在主线程上调用一个方法并等待它完成,然后再调用池排出。
invocation = [NSInvocation invocationWithTarget:feedDelegate
selector:@selector(operation:didGetFeed:)
retainArguments:YES, self, feedDetailsModel];
但这仍然不一定解释为什么操作池会导致 View Controller 被释放。想法?
编辑:顺便说一句,我无法重现这一点。我只在我们的测试人员和野外人员的崩溃报告中看到过它。
编辑2:自动释放池非常简单,它在操作的main
方法开始时分配,并在工作完成时耗尽。
最佳答案
如果您在耗尽自动释放池期间崩溃,则意味着您在该事件循环期间过度释放了某些内容。如果同一个对象具有自动释放功能,那么在池耗尽之前您不会看到崩溃。这并不意味着自动释放与它有任何关系。那正是最后一次发布的时间。
确保您使用访问器来访问所有属性(除了 init 和 dealloc)。如果这种类型在非 ARC 代码中崩溃,直接访问 ivars 是第一大原因。无论如何,您都需要审核保留和释放的平衡。迁移到 ARC 通常会减少此类错误,如果可能的话,强烈建议迁移到 ARC。
关于ios - NSAutoReleasePool 释放 View Controller ?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/15753087/