我偶尔会看到像这样的堆栈跟踪崩溃:
0 libobjc.A.dylib 0x97dc0edb objc_msgSend + 27
1 com.apple.CoreData 0x97edcdc2 -[_PFManagedObjectReferenceQueue _queueForDealloc:] + 162
2 com.apple.CoreData 0x97edccbe -[NSManagedObject release] + 94
3 com.apple.CoreFoundation 0x9318ef38 CFRelease + 152
4 com.apple.CoreFoundation 0x931a7460 __CFBasicHashStandardCallback + 384
5 com.apple.CoreFoundation 0x931a706e __CFBasicHashDrain + 478
6 com.apple.CoreFoundation 0x9318f101 _CFRelease + 353
7 com.apple.CoreFoundation 0x931bbc6d _CFAutoreleasePoolPop + 253
8 com.apple.Foundation 0x973270aa NSPopAutoreleasePool + 76
9 com.apple.Foundation 0x97326fd2 -[NSAutoreleasePool drain] + 130
10 com.apple.AppKit 0x95087185 -[NSApplication run] + 627
11 com.apple.AppKit 0x9507f2d9 NSApplicationMain + 574
12 com.karelia.Sandvox 0x70001ef6 start + 54
不幸的是,它的重现是相当随机的。有谁知道什么可能导致这样的崩溃?似乎没有人提到过,这没有帮助-_queueForDealloc:
之前在网上看过!
我对过去的类似问题有一个模糊的记忆,这是在仍附加 KVO 观察者的情况下释放托管对象的症状。有人同意吗?
最终能够在开发计算机上重现该问题,这次崩溃似乎是上下文拆卸期间早期异常的副作用。
事件的顺序是这样的:
- The
MOC
正在被释放,所以是时候拆除它的内容了
- 为此,所有注册
MOs
变成故障*
- 转动 a 的动作
MO
发生故障时发送 KVO 通知
- 观察者收到通知并尝试对其采取行动,点击了现在无效的
MO
在图中
- Core Data 因无效访问而引发异常
- 由于未知原因,该异常未传递给我的异常报告者
- The
MO
s 被释放,但异常使 Core Data 处于意外状态,因此MO
释放崩溃
简而言之,真正的问题是观察者比环境更长久。不要允许他们这样做!任何观察到的物体MO
也许还应该有一个强烈的参考MOC
, like NSObjectController
和朋友们一样。
*我在测试中发现Core Data经常在后台线程上执行此操作,大概是为了避免阻塞主线程
MOC
– 管理对象上下文
MO
– 管理对象
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)