核心数据保存无法识别的select器exception
这是一个很长的一段时间，因为谷歌search返回一无所获。 有时，往往足够的地方值得进一步调查，但往往不够我可以追踪什么时候或如何发生，我得到以下exception，当我调用save:在NSManagedObjectContext ：
-[_NSObjectID_48_0 _stateFlags]: unrecognized selector sent to instance 0x8675570
上下文是types为NSPrivateQueueConcurrencyType的子上下文，它是NSPrivateQueueConcurrencyTypetypes的主上下文的子NSMainQueueConcurrencyType 。
除了堆栈跟踪之外，我实在没有任何进一步的信息： 
任何密码技术人员能否从堆栈跟踪中找出任何可能的想法来解决这个问题？
日志消息指出由于某种原因，我们正在寻找_stateFlags上的属性/方法_NSObjectID_48_0 ，其中一个是私有API，另一个是私有类。
快速运行
class-dump /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
似乎表明（除其他地方） _stateFlags是NSManagedObject上的私人API。 我在Mac上找不到任何对名为_NSObjectID_48_0的私有类的引用，但仅基于名称，似乎与NSManagedObjectID有关。
这是一个远射，但我想知道，如果你有在某个时候通过一个NSManagedObjectID NSManagedObject预期而不是？ grep你的代码显式强制NSManagedObject不会伤害。
另一个罪魁祸首可能是NSManagedObjectID插入到弱types的数据结构（字典/数组/集我看着你），这可能会让你“胁迫”到NSManagedObject而不明确它。
我们遇到了同样的问题。 这是由NSManagedObjectContext :: reset的调用引起的。 重置将使属于调用重置的上下文的所有NSManagedObjects无效。 继续使用已经失效的NSManagedObject实例可能会导致意外的结果。 这是那些意想不到的结果之一。
我今年在WWDC与Xcode工程师讨论过这个问题。 当你在debugging器中得到这个exception时，你不能告诉任何关于这个对象的信息。 但是，如果您查看控制台应用程序中的崩溃日志，他们确实有对象无法响应select器[我想这是正确的]。
您需要让应用程序崩溃，而不运行debugging器 – 所以系统处理崩溃。
同步你的手机。
打开控制台〜/ Library / Logs / CrashReporter / MobileDevice /，find崩溃报告，并查看报告。 我被告知要在这里input一个错误 – 这个lldb应该提供同样的细节 – 我做了！
希望这可以帮助你。