因此,我对从崩溃日志中检测到的崩溃日志进行故障排除有点困难。该应用程序崩溃了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行,它就会在工作结束时耗尽操作的自动释放池。
所以我想弄清楚为什么自动释放池会试图释放委托。对委托的引用将传递给操作类:
@property (assign) id <CCGetFeedOperationDelegate> feedDelegate;
我能想到的唯一一件事就是我在主线程上调用一个方法并等待它在调用池流失之前完成。
invocation = [NSInvocation invocationWithTarget:feedDelegate
selector:@selector(operation:didGetFeed:)
retainArguments:YES, self, feedDetailsModel];
但这仍然不一定能解释为什么操作池会导致视图控制器被释放。想法?
编辑:顺便说一下,我无法重现这个。我只是在我们的测试人员和野外人员的崩溃报告中看到过它。
编辑2:自动释放池非常简单,它在操作的main
方法的开头分配,并在工作完成后耗尽。
答案 0 :(得分:4)
如果您在耗尽自动释放池时崩溃,那只意味着您在该事件循环期间过度释放某些内容。如果同一个对象上有自动释放,那么在池耗尽之前你不会看到崩溃。这并不意味着autorelease与它有任何关系。那就是最后一次发布的时候。
确保您使用访问器进行所有属性访问(init和dealloc除外)。如果非ARC代码崩溃,那么直接访问ivars是第一个原因。无论如何,您需要审核保留和释放的平衡。如果出现错误,迁移到ARC通常会减少这些类型,如果可能,强烈建议使用。