有沒有辦法模擬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發佈孤立對象的過程？

回答

相關問題