NSAutoReleasePool发布视图控制器？

因此，我正在对我从测试仪获得的崩溃日志进行故障排除时遇到了一些困难。该应用程序与EXC_CRASH (SIGSEGV)崩溃，并且在任何线程的唯一识别码是在线程6.堆栈跟踪看起来是这样的：NSAutoReleasePool发布视图控制器？

... 
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，它只是排出操作的自动释放池在其工作结束时。

所以我想弄清楚为什么autorelease池会试图释放委托。给委托的引用传递给操作类这样：

@property (assign) id <CCGetFeedOperationDelegate> feedDelegate;

我能想到的唯一的事情就是我调用主线程的方法，并等待它调用池前完成排水。

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

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

编辑：顺便说一句，我还没有能够重现这一点。我只在我们的测试人员和野外人员的崩溃报告中看到它。

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

来源

2013-04-01 Joel Martinez

如果您在耗尽自动释放池期间崩溃，那只意味着您在该事件循环期间过度释放了某处。如果同一个对象上有autorelease，那么直到游泳池消失时才会看到崩溃。这并不意味着autorelease与它有任何关系。那是刚刚发布的最后一个版本。

确保您使用访问器来访问所有属性（init和dealloc除外）。如果在非ARC代码中崩溃，则直接访问ivars是首要原因。无论如何，您需要审核您对保留和释放的平衡。转移到ARC通常会减少这些类型，如果可能的话，强烈建议。

来源

2013-04-02 00:16:05

感谢您的回答。是的，我意识到游泳池如何工作的机制。这里的问题是我不知道视图控制器如何进入autorelease池。它在主线程上分配，作为仅分配属性设置到操作上。控制器如何进入游泳池？我同意，转移到ARC将是最终目标，这是......只是还没有到那里:) –

对象总是进入游泳池。每次访问一个原子属性获取器时，它都会获取一个保留/自动释放对。许多方法，尤其是处理线程安全的方法，都附加了额外的保留/自动释放对。这是确保对象继续存在直到方法结束的一种常用方法。一个常用的setter模式也是在设置新值之前自动释放旧值。所以在autorelease池中显示对象是很常见的，即使你没有故意自动释放它们。 –

啊......这很好，谢谢。它解释了为什么它在那里，显然它在这种情况下被过度释放。好吧，现在找到罪魁祸首：P –

NSAutoReleasePool发布视图控制器？

回答

相关问题