Obj-C消息發送到釋放對象（EXEC_BAD_ACCESS），與iOS5，ARC

我正在開發一個iOS5應用程序使用ARC，我開始得到一些隨機EXEC_BAD_ACCESS崩潰，我想不出來..隨機我的意思是它是非常不可預測的：有時可能需要很長時間才能崩潰，有時候會很短。也沒有一個特定的按鈕/表格單元/等。這會引發崩潰。每個用戶交互都可能導致應用程序崩潰，但不能重複崩潰。Obj-C消息發送到釋放對象（EXEC_BAD_ACCESS），與iOS5，ARC

我試圖打開NSZombie和一些malloc調試工具。在儀器中，崩潰錯誤如下：一個Objective-C消息被髮送到地址爲：0x10bd1b40的釋放對象（殭屍）。並且參考計數日誌的最後一部分看起來像這樣：

475 CoursesFirstViewController Release 2 02:23.253.631 0 UIKit -[UINibDecoder finishDecoding] 
476 CoursesFirstViewController Release 1 02:23.253.838 0 Foundation -[NSAutoreleasePool drain] 
477 CoursesFirstViewController Zombie -1 02:35.752.420 0 Foundation objectHash

2,1，-1是引用計數。我不知道爲什麼它跳過0並下降到-1，導致程序崩潰（所有條目但最後都有連續的引用計數）。我也不知道objectHash是什麼。

我的應用程序包含多個功能，可以在我的主屏幕上作爲圖標訪問。 CoursesFirstViewController是其中的一個功能。總是，即使我在其他地方，它是課程第一視圖控制器和對象哈希會使應用程序崩潰。（上面的日誌是這樣的：我在02:23離開CoursesFirstViewController（從而返回到我的應用程序的主屏幕），但在12秒後，當我在其他功能中時，應用程序崩潰），我只需要輸入CourseFirstViewController，稍微攪拌一下，然後到其他地方繼續使用該應用程序，過一會兒它就會崩潰。

我現在真的很生氣這個問題。我已經搜索了SO和Google很長一段時間，但找不到解決方案。任何幫助將非常感激。謝謝！！

來源

2012-01-21 aforaudrey

您是否設法獲得堆棧跟蹤幾次發生，或者它是唯一的一次？ – zneak

@zneak抱歉什麼是堆棧跟蹤？它是NSLog（@「％@」，[NSThread callStackSymbols]）; ？每次崩潰日誌的最後幾行看起來像上面那樣。 – aforaudrey

在儀器中，從菜單欄中選擇查看>擴展詳細信息。然後，當您單擊引用計數日誌中的事件時，擴展詳細視圖將顯示事件發生時的調用堆棧（堆棧跟蹤）。 –

@robmayoff yea我已經檢查過，但沒有看到任何特別有用的東西。最後幾個調用是objectHash，hashProbe，[NSConcreteHashTable rehashAround]，[NSConcreteHashTable removeItem]等。

這實際上有些用處。這告訴我們一個集合，可能是NSDictionary，但可能是NSSet正在被銷燬。從你之前的信息看來，它似乎是在筆尖實例化過程中創建的自動收集集合（可能是CoursesFirstViewController的一個ivar）。無論如何，鑑於這些症狀，我就會在那裏看到，但這次事故似乎證實了這一點。

一般建議審覈任何__bridge強制轉換或unsafe_unretained屬性。

另一種預感是，您以違反可可內存管理的方式命名方法。最可能的錯誤是你有一個財產，開始new或copy。如果您的ARC代碼調用被誤稱爲非ARC代碼，這肯定會成爲問題。

來源

2012-01-21 04:19:32

我現在80％確定它是導致麻煩的搜索功能，雖然我還沒有弄清楚具體是怎麼做的，我會看一看searchResults集合，看看它們是否有什麼問題，謝謝！ – aforaudrey

感謝Rob，這是一些NSDictionary引起我的麻煩。究竟是什麼問題，但我重寫了搜索功能，現在一切正常。讚賞！ – aforaudrey

聖牛。我們有一個名爲「newRequirements」的Core Data屬性。它工作得很好，直到我們使用XCode5來構建。然後我們到處都是殭屍。將CoreData模型屬性重命名爲「nextRequirements」對其進行排序。花了大約6個小時來找出並修復那個。感謝提示。 – tobinharris

我懷疑你的某個屬性被標記爲「弱」，當它應該是「強大的」並且在你訪問它之前超出範圍並獲得釋放。在這種情況下，ARC無法爲您節省，並且您將獲得上述隨機碰撞行爲。

如果你沒有找到它的運氣，我會採取在你的項目上做一個「弱」屬性的全球搜索，並仔細檢查每一個，以確保它不是你期望的東西。這很乏味，但說實話並不需要那麼長時間，有時甚至比一個bug還要多。

來源

2012-01-21 03:23:18 spoofwear

當對象被釋放時，標記爲'weak'的屬性被設置爲nil，所以在這種情況下你不應該看到殭屍消息。標記爲'assign'或'unsafe_unretained'的屬性可能會指向殭屍。 –

實際上ARC在這種情況下確實可以防止崩潰，因爲它可以消除關於釋放的弱引用指針。 – dasblinkenlight

我認爲與我的CoursesFirstViewController相關的一切都很強大。只有一些Xcode創建的IBOutlet很弱，而且它們都在其他一些功能中，所以不應該是原因。（如果我至少沒有訪問CFVC一次，那麼一切似乎都沒有問題。） – aforaudrey

我從你的儀器輸出中收集到殭屍對象是CoursesFirstViewController。我們經常使用視圖控制器作爲其他對象的委託，並且大多數具有委託的對象不保留其委託。

我假設您沒有使用任何unsafe_unretained屬性或變量或任何retain-類型屬性。所以我認爲你的任何物體都不會對殭屍提供一個懸而未決的參考。

由於系統庫必須使用非ARC代碼，因此它們不使用ARC的弱引用。因此，如果某個系統對象具有CoursesFirstViewController作爲它的代表，並且CoursesFirstViewController被銷燬但系統對象不是，那麼系統對象留下一個對被銷燬對象的懸掛引用。

因此，檢查您是否使用CoursesFirstViewController作爲任何系統對象的代表。如果是這樣，你確定這些物體沒有超過CoursesFirstViewController？

來源

2012-01-21 04:01:17

我使用'CoursesFirstViewController'作爲'UISearchBarDelegate'和'UISearchDisplayDelegate'。但我認爲，因爲這些是視圖控制器UI的組件，它們不應該超過'CoursesFirstViewController'？唯一的另一件事是我正在使用不使用ARC的'ASIHttpRequest'，並且我有一些本地'ASIHTTPRequest'變量，其代表被設置爲'CoursesFirstViewController'。但我在我的程序的其他地方也使用了'ASIHTTPRequest'，它們看起來很好，所以我對此不太確定。 – aforaudrey

通常，視圖控制器的視圖層次中的UI元素被視圖控制器被銷燬。但是你可能會保留其中一個參考。（你應該知道你是不是。）我不熟悉'ASIHttpRequest'，所以我肯定會建議調查這些對象是否可以勾畫視圖控制器。一個'ASIHttpRequest'產生一個線程，或者註冊一些網絡活動的異步通知？這可能會保留'ASIHttpRequest'，讓它超出視圖控制器。 –

我剛剛修改了'ASIHTTPRequest'對象，以便它們不再具有'CoursesFirstViewController'作爲它們的委託。然而，崩潰仍然存在..但我也不認爲搜索顯示控制器或搜索欄可以以某種方式超過'CoursesFirstViewController' ... :( – aforaudrey

Obj-C消息發送到釋放對象（EXEC_BAD_ACCESS），與iOS5，ARC

回答

相關問題