有没有办法模拟iOS发布孤立对象的过程？

我有一个流行的iOS应用程序，但我得到了一些总是在同一行上的崩溃报告。我无法重现我的生活中的错误，但我怀疑它与我的第三方库没有使用ARC有关，所以当它不应该被发布时就会发布。有没有办法模拟iOS发布孤立对象的过程？

我试过模拟内存警告，我尝试过使用malloc随机使用内存，我无法重现该错误。但这种情况经常发生，很多人每天都会收到电子邮件并抱怨。

我知道操作系统做了一些“清理”，释放需要自动发布的对象，但有没有办法在模拟器中强制这样做？

2013-08-30 Philosophistry

ARC和非ARC编译代码可以完美结合，没有任何问题。这是因为ARC'只''为你插入'保留'和'释放'。所以一定有别的东西。显示崩溃报告！ –

这里是崩溃报告：http://pastebin.com/UnVPh543我收到了几份报告，每天都准确地在DBRequest.m的同一部分结束，但没有人能够可靠地重现它。 – Philosophistry

这个SO问题具有相同类型的崩溃：http://stackoverflow.com/questions/12901031/segv-accerr-calling-nsnotificationcenter-defaultcenter-removeobserverselfi-i – trojanfoe

消息正在发送到释放对象。

有人正试图与释放的DBRequest进行通信，或者DBRequest正试图与释放的对象进行通信。

这种情况最常见的原因是，如果你做这样的事情：

[DBRequest setNetworkRequestDelegate:self]; 
DBRequest *myDBRequest = [DBRequest initWithURLRequest:request andInformTarget:self selector:@selector(doSomething)];

然后，您可以启动一些网络活动，用户移动到另一种观点认为，这将释放self，网络活动结束，并试图通知self它已完成。

确保在100％的通知对象将被释放的情况下调用[myDBRequest cancel];。对此，dealloc方法通常是安全的。

来源

2013-08-30 06:15:12

这里有一点更多的解释：http://stackoverflow.com/a/1072212/1445366 –

+1看起来似乎合情合理。你能解释为什么在这种情况下子代码是'SEGV_ACCERR'而不是'SEGV_MAPERR'？ – trojanfoe

尽管这是一个很好的答案，但问题可能会更加微妙：假设dealloc方法在主线程（例如UI控制器）上执行。假设'cancel'很可能具有“异步”风格 - 其效果即在接收器中将委托设置为零，可能是“稍后发生”，可能是同步的，即与接收器上运行的其他任务串行化。所以，有一个潜在的*竞争条件* - 应用程序可能仍然崩溃。 – CouchDeveloper

有没有办法模拟iOS发布孤立对象的过程？

回答

相关问题