2

因此，我在对从我们的测试仪获得的崩溃日志进行故障排除时遇到了一些困难。该应用程序因 崩溃而崩溃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)
...

如果您查看第 102 行CCGetFeedOperation，它只是在工作结束时耗尽了操作的自动释放池。

所以我试图弄清楚为什么自动释放池会试图释放委托。对委托的引用被传递给操作类，如下所示：

@property (assign) id <CCGetFeedOperationDelegate> feedDelegate;

我唯一能想到的是我在主线程上调用一个方法并等待它完成，然后再调用池排水。

invocation = [NSInvocation invocationWithTarget:feedDelegate
                                                       selector:@selector(operation:didGetFeed:) 
                                            retainArguments:YES, self, feedDetailsModel];

但这仍然不能解释为什么操作的池会导致视图控制器被释放。想法？

编辑：顺便说一句，我无法重现这个。我只在我们的测试人员和野外人员的崩溃报告中看到过它。

编辑2：自动释放池非常简单，它在操作main方法开始时分配，并在工作完成时耗尽。

4

1 回答 1

4

如果你在释放自动释放池的过程中崩溃，那只是意味着你在那个事件循环中的某个地方过度释放了一些东西。如果同一个对象上有自动释放，那么在池耗尽之前您不会看到崩溃。这并不意味着自动释放与它有任何关系。那是最后一次发布的时候。

确保您使用访问器进行所有属性访问（除了 init 和 dealloc）。如果这种情况在非 ARC 代码中崩溃，直接访问 ivars 是第一大原因。在任何情况下，您都需要审核保留和释放的平衡。如果出现错误，迁移到 ARC 通常会减少这些类型，如果可能，强烈建议使用。

于 2013-04-02T00:16:05.327 回答