無法識別的核心數據保存選擇器異常

這是一個遠射，因爲谷歌搜索沒有返回任何內容。有時候，往往不夠的地方值得進一步調查，但不是經常不夠，我可以追查的時候，或者它究竟是如何發生的，我得到下面的異常，當我打電話上一個NSManagedObjectContext：無法識別的核心數據保存選擇器異常

-[_NSObjectID_48_0 _stateFlags]: unrecognized selector sent to instance 0x8675570

的背景是孩子上下文類型爲NSPrivateQueueConcurrencyType，它是NSMainQueueConcurrencyType類型的主要上下文的子節點。

我真的沒有比堆棧跟蹤其他任何進一步的信息： enter image description here

任何密碼學家能做出什麼出格的堆棧跟蹤變出一些可能的想法，問題可能是什麼？

來源

2012-08-24 Snowman

鑑於發生這種情況 - 在「驗證」 - 它會導致我認爲一些託管對象有一個「驗證」的方法，並試圖發送「stateFlags」的一些其他對象。你有權訪問代碼或模型嗎？你可以搜索源代碼嗎？您可以在方法「stateFlags」上設置一個斷點並「捕捉」發送它的對象。 –

這些消息的問題是，很難找出問題出在哪裏。我發現嘗試打印「實例0x ....」看看是否看起來很熟悉通常會有所幫助;在gdb中做「po（NSObject *）0x8675570」。如果你幸運的話，你可以重新設計一個你的對象，然後找出你將它傳遞給你不應該傳遞給它的東西，或者你必須添加一些東西使它符合某些東西。 –

@DavidH我的任何對象都沒有自定義的驗證方法，上面看到的所有驗證方法都是內部的。即使它不在我的代碼中，是否仍然有辦法在某處設置斷點？ @ ChristianStieber好吧，我必須等到下一次我從現在開始出現這個崩潰時，我真的不能重現它。它只是來來去去。我如何使用LLDB打印對象？ – Snowman

日誌消息表明由於某種原因，我們正在尋找_NSObjectID_48_0上的屬性/方法_stateFlags，其中一個是私有API，另一個是私有類。

的

class-dump /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData

一個快速運行似乎表明，（其他地方）_stateFlags是NSManagedObject私有API。我無法在Mac上找到對名爲_NSObjectID_48_0的私人類的引用，但僅基於名稱，似乎與NSManagedObjectID有關。

這是一個遠射，但我想知道你是否在某個時間點通過了NSManagedObjectID，而預期的是NSManagedObject？它不會傷害你的代碼，以明確的強制NSManagedObject。

另一個罪魁禍首可能是NSManagedObjectID插入到弱類型的數據結構（字典/數組/集我看着你），這可能會讓你「脅迫」到NSManagedObject而不明確它。

來源

2012-08-25 01:48:54 Drew

我今年在WWDC上與Xcode工程師討論過這個問題。當你在調試器中得到這個異常時，你無法告訴任何關於該對象的信息。但是，如果您查看控制檯應用程序中的崩潰日誌，他們會發現無法響應選擇器的對象[我認爲這是正確的]。

您需要讓應用程序崩潰而不運行調試器 - 因此係統會處理崩潰。

同步您的手機。

打開控制檯〜/ Library/Logs/CrashReporter/MobileDevice /，找到崩潰報告並查看報告。我被告知要在這方面輸入一個錯誤 - 那個lldb應該提供相同的細節 - 我做了！

希望這可以幫助你。

來源

2012-08-24 20:56:43

我們遇到了同樣的問題。這是由調用NSManagedObjectContext :: reset引起的。重置將使屬於調用重置的上下文的所有NSManagedObjects無效。繼續使用已經失效的NSManagedObject實例可能會導致意外的結果。這是那些意想不到的結果之一。

來源

2012-09-17 20:14:36 Steve

無法識別的核心數據保存選擇器異常

回答

相關問題