因此,我在对从我们的测试人员那里获得的崩溃日志进行故障排除时遇到了一些困难。应用程序因 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
selectorselector(operation:didGetFeed
retainArguments:YES, self, feedDetailsModel];
但这仍然不能解释为什么操作的池会导致 View Controller 被释放。想法?
编辑:顺便说一句,我无法重现这一点。我只在我们的测试人员和野外人员的崩溃报告中看到它。
编辑 2:自动释放池非常简单,它在操作的 main 方法开始时分配,并在工作完成时排出。
Best Answer-推荐答案 strong>
如果您在排空自动释放池的过程中崩溃,那仅意味着您在该事件循环中的某个地方过度释放了某些东西。如果同一个对象上有自动释放,那么在池耗尽之前您不会看到崩溃。这并不意味着自动释放与它有任何关系。那是最后一次发布的时候。
确保对所有属性访问使用访问器(init 和 dealloc 除外)。如果这种情况在非 ARC 代码中崩溃,直接访问 ivars 是第一大原因。在任何情况下,您都需要审核保留和释放的平衡。如果出现错误,迁移到 ARC 通常会减少这些类型,如果可能,强烈建议使用。
关于ios - NSAutoReleasePool 释放 View Controller ?,我们在Stack Overflow上找到一个类似的问题:
https://stackoverflow.com/questions/15753087/
|