Crash with NSManagedObject release：“objc_msgSend（）selector name：_queueForDealloc” [英] Crash with NSManagedObject release: "objc_msgSend() selector name: _queueForDealloc"
问题描述
我遇到了一个奇怪的崩溃报告由许多用户通过HockeyApp与以下堆栈跟踪。它似乎与在不同的调度队列中发布的NSManagedObject有关的事情...但我没有得到任何符号的问题可能在哪里。它看起来像一个内存管理问题，但我使用ARC，所以不知道如何会过度释放一个NSManagedObject。
这是我收到的崩溃报告（主线程在不同的时间显示不同的跟踪）：
代码类型：ARM-64
父进程：launchd [1]
日期/时间：2014-05-12T05：43：54Z
操作系统版本：iPhone OS 7.0.6（11B651）
报告版本：104
异常类型：SIGSEGV
异常代码：SEGV_ACCERR在0x1c3dbeb8
崩溃的主题：2
应用程序特定信息：
objc_msgSend（）选择器名称：_queueForDealloc：
线程0：
0 CoreFoundation 0x000000018e384618 CFNumberGetType + 0
1 CoreFoundation 0x000000018e3333b8 _CFAppendXML0 + 2768
2的CoreFoundation 0x000000018e333304 _CFAppendXML0 + 2588
3的CoreFoundation 0x000000018e332268 _CFPropertyListCreateXMLData + 196
4基金会0x000000018ef152f4 - [NSDictionary中（的NSDictionary）将writeToFile：原子：] + 232
5 simplelist中0x00000001001ae48c __55- [SharedSettingController writeToContactsReferenceFile] _block_invoke（SharedSettingController.m：620）
6 libdispatch.dylib 0x000000019a974420 _dispatch_call_block_and_release + 20
7 libdispatch.dylib 0x000000019a9743e0 _dispatch_client_callout + 12
8 libdispatch.dylib 0x000000019a97756c _dispatch_main_queue_callback_4CF + 340
9的CoreFoundation 0x000000018e3e6d64 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
10的CoreFoundation 0x000000018e3e50a4 __CFRunLoopRun + 1448
11的CoreFoundation 0x000000018e325b38 CFRunLoopRunSpecific + 448
12 GraphicsServices 0x0000000193d4b830 GSEventRunModal + 164
13的UIKit 0x00000001913640e8 UIApplicationMain + 1152
14 SimpleList 0x000000010006347c _mh_execute_header（main.m：18）
15 libdyld.dylib 0x000000019a98faa0 start + 0
线程1：
0 libsystem_kernel.dylib 0x000000019aa71ac8 kevent64 + 8
1 libdispatch.dylib 0x000000019a975d78 _dispatch_mgr_thread + 48
线程2崩溃：
0 libobjc.A.dylib 0x000000019a39f9d0 objc_msgSend + 16
1 CoreData 0x000000018e13b284 - [NSManagedObject发布] + 168
2 CoreData 0x000000018e131154 - [_ PFArray dealloc] + 96
3 libobjc.A.dylib 0x000000019a3a13d4（匿名命名空间）:: AutoreleasePoolPage :: pop（void *）+ 520
4 libdispatch名为.dylib 0x000000019a97b428 _dispatch_root_queue_drain + 440
5 libdispatch.dylib 0x000000019a97b638 _dispatch_worker_thread2 + 72
6 libsystem_pthread.dylib 0x000000019ab09918 _pthread_wqthread + 352
7 libsystem_pthread.dylib 0x000000019ab097a8 start_wqthread + 0
主题3：
0 libsystem_kernel.dylib 0x000000019aa71cc0 mach_msg_trap + 8
1的CoreFoundation 0x000000018e3e6cac __CFRunLoopServiceMachPort + 180
2的CoreFoundation 0x000000018e3e4e3c __CFRunLoopRun + 832
3的CoreFoundation 0x000000018e325b38 CFRunLoopRunSpecific + 448
4基金会0x000000018ef127fc + [NSURLConnection的（装载机）_resourceLoadLoop：] + 344
5基金会0x000000018efa0770 __NSThread__main__ + 996
6 libsystem_pthread.dylib 0x000000019ab0c1b0 _pthread_body + 164
7 libsystem_pthread.dylib 0x000000019ab0c108 _pthread_start + 136
8 libsystem_pthread.dylib 0x000000019ab097b0 thread_start + 0
主题4：
0 libsystem_kernel.dylib 0x000000019aa8a76c __select + 8
1 libsystem_pthread.dylib 0x000000019ab0c1b0 _pthread_body + 164
2 libsystem_pthread名为.dylib 0x000000019ab0c108 _pthread_start + 136
3 libsystem_pthread.dylib 0x000000019ab097b0 thread_start + 0
主题5：
0 libsystem_kernel.dylib 0x000000019aa8ae74 __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x000000019ab097a8 start_wqthread + 0
线程6：
0 libsystem_kernel.dylib 0x000000019aa8ae74 __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x000000019ab097a8 start_wqthread + 0
线程7：
0 libsystem_kernel.dylib 0x000000019aa8ae74 __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x000000019ab097a8 start_wqthread + 0
线程2用ARM-64崩溃线程状态：
pc：0x000000019a39f9d0 fp： 0x0000000102b479c0 SP：0x0000000102b479a0 X0：0x00000001782451f0
X1：0x000000018e2eeb56 X2：0x00000001705336a0 X3：0x000000019aac3d18 X4：0x0000000000000001
X5：0x0000000000000010 5233：0x000000017013f900 X7：0x0000000000000000 X8：0x000000019ad5bdb8
X9：0x000000001c3dbea8 X10：0x0000000000000000 X11 ：0x000000230000003f X12：0x000000014f073410
X13：0xbadd5bcc1c3dbead X14：0xffffffffffffffff X15：0x0000000000000001 X16：0x000000019a39f9c0
X17：0x000000018e13b1d8 X18：0x0000000000000000 X19：0x00000001705336a0 X20：0x000000019ad7b000
X21：0x000000019adc9200 X22：0x000000019ad7b000 X23：0x0000000000000715 X24：0x0000000000000010
X25：0x0000000102a64038 X26：0xa3a3a3a3a3a3a3a3 X27：0x0000000000000001 X28：0x0000000000000000
LR：0x000000018e13b284 CPSR：0x0000000020000000
在启动时，我会启动一些派遣队列做一些后台工作（他们使用一个单独的MOC来加载托管对象和处理它们），所以这些可能负责，但队列被标记在我的应用程序，和堆栈跟踪似乎不显示哪个队列负责（如果它是我自己的队列）。我已经运行应用程序与NSZombies启用，但是没有帮助。我还运行了静态分析工具，并且不会打开任何东西。
任何想法可能会导致这个问题，我可以做什么来调试它？
编辑：
我确定我可以将问题区域分离成一段代码
SLAppDelegate * delegate =（SLAppDelegate *）[[UIApplication sharedApplication] delegate];
dispatch_async（delegate.coreDataController.filterMainQueue，^ {
NSManagedObjectContext * backgroundContextImage = [[NSManagedObjectContext alloc] init];
[backgroundContextImage setPersistentStoreCoordinator：delegate.coreDataController.persistentStoreCoordinator];
NSArray * items = [Person getAllPersonsWithContext：backgroundContextImage];
//可能更新一些项目
dispatch_async（dispatch_get_main_queue（），^ {
//文件在另一个dispatch_asyn（dispatch_get_main_queue）
[[SharedSettingController sharedSettings] writeToContactsReferenceFile];
};
}）;
我只是不知道这是什么错误。它99％的时间工作正常，但1％是导致几个崩溃，我很想得到解决。
解决方案当在
NSOperation，我们最终通过弱化任何参数和使用私有@autoreleasepool来解决它。
我们当前的设置有一个
NSOperationQueue，它有一个长时间运行的计算在背景中。该操作首先创建一个私有的被管对象上下文，将父集合作为主对象上下文，并去取它的对象。
同时，我们有一个单独的
NSOperationQueue在其他地方同步我们的服务器的新数据，可能添加，更新或删除我们的计算操作使用的对象。
我们首先在野外看到一堆崩溃，在本地再现的唯一方法是让计算和同步操作连续运行，5-10分钟后，我们会看到类似于下面的崩溃：
线程：崩溃：background queue :: NSOperation 0x18f43c90
0 libobjc.A.dylib 0x36f11f46 objc_msgSend + 5
1 CoreData 0x2928408f - [NSManagedObject release] + 166
2 CoreData 0x2927b4d7 - [_ PFArray dealloc] + 94
3 libobjc.A.dylib 0x36f201a9（匿名命名空间）:: AutoreleasePoolPage :: pop *）+ 404
4的CoreFoundation 0x294713a9 _CFAutoreleasePoolPop + 16
5基金会0x2a1b6453 - [__ NSOperationInternal _start：] + 1058
6基金会0x2a25b44b __NSOQSchedule_f + 186
7 libdispatch.dylib 0x3746d651 _dispatch_queue_drain + 952
8 libdispatch.dylib 0x3746809d _dispatch_queue_invoke + 84
9 libdispatch.dylib 0x3746eba1 _dispatch_root_queue_drain + 320
10 libdispatch.dylib 0x3746fcd7 _dispatch_worker_thread3 + 94
11 libsystem_pthread.dylib 0x375c6e31 _pthread_wqthread + 668
线程：崩溃：background queue :: NSOperation 0x1db59e80
0 libsystem_kernel.dylib 0x3722edfc __pthread_kill + 8
1 libsystem_pthread.dylib 0x372acd37 pthread_kill + 62
2 libsystem_c.dylib 0x371ce909 abort + 76
3 libsystem_malloc.dylib 0x37258331 szone_size
4 libobjc.A.dylib 0x36bf1621 object_dispose + 20
5 CoreData 0x28ec571d - [_ PFManagedObjectReferenceQueue dealloc] + 80
6 CoreData 0x28e5630f - [NSManagedObject dealloc] + 166
CoreData 0x28e55217 - [_ PFManagedObjectReferenceQueue _queueForDealloc：] + 246
8 CoreData 0x28e5508f - [NSManagedObject release] + 166
9 CoreData 0x28e4c4d7 - [_ PFArray dealloc] + 94
10 libobjc.A.dylib 0x36c031a9（匿名命名空间）:: AutoreleasePoolPage :: pop（void *）+ 404
11 CoreFoundation 0x29042149 _CFAutoreleasePoolPop + 16
12基础0x29d88c23 - [__ NSOperationInternal _start ：] + 1058
13基金会0x29e2dc1b __NSOQSchedule_f + 186
14 libdispatch.dylib 0x371505b1 _dispatch_queue_drain + 952
15 libdispatch.dylib 0x3714af85 _dispatch_queue_invoke + 84
16 libdispatch.dylib 0x37151b9b _dispatch_root_queue_drain + 338
17 libdispatch.dylib 0x37152cd7 _dispatch_worker_thread3 + 94
18 libsystem_pthread.dylib 0x372a9e31 _pthread_wqthread + 668
线程：崩溃：NSOperationQueue序列队列
0 libsystem_kernel。 dylib 0x396871f0 __pthread_kill + 8
1 libsystem_pthread.dylib 0x396ef7b7 pthread_kill + 58
2 libsystem_c.dylib 0x39637ff9中止+ 76
3 libsystem_malloc.dylib 0x396aed25 szone_size
4 libobjc.A.dylib 0x390d93a9 object_dispose + 20
5 CoreData 0x2e3d4081 - [_ PFManagedObjectReferenceQueue dealloc] + 80
6 CoreData 0x2e3655b7 - [NSManagedObject dealloc] + 166
CoreData 0x2e364501 - [_ PFManagedObjectReferenceQueue _queueForDealloc：] + 244
8 CoreData 0x2e36437d - [NSManagedObject release] + 164
9 CoreData 0x2e35b867 - [_ PFArray dealloc] + 94
10 libobjc.A.dylib 0x390e20d3（匿名命名空间）:: AutoreleasePoolPage :: pop（void *）+ 358
11的CoreFoundation 0x2e5294c1 _CFAutoreleasePoolPop + 16
12基金会0x2ef29999 - [__ NSOperationInternal _start：] + 1064
13基金会0x2efcd745 __NSOQSchedule_f + 60
14 libdispatch.dylib 0x395c0cbd _dispatch_queue_drain + 488
15 libdispatch.dylib 0x395bdc6f _dispatch_queue_invoke + 42
16 libdispatch.dylib 0x395c15f1 _dispatch_root_queue_drain + 76
17 libdispatch.dylib 0x395c18dd _dispatch_worker_thread2 + 56
18 libsystem_pthread.dylib 0x396ecc17 _pthread_wqthread + 298
我们多次检查代码，无法确定崩溃的原因。我们尝试启用NSZombies，但是在我们可以得到重现之前会耗尽内存。
我们最后做的是以下两件事：
@autoreleasepool
在
[privateObjectContext performBlockAndWait：^ {...} ]，它位于我们的NSOperationBlock内，我们将所有的代码包装在@autoreleasepool {...}。这样，在该代码块中检索的所有NSManagedObject将在离开performBlockAndWait之前标记为释放。
weakify / strongify
包含NSManagedObjects的任何参数在传递到块之前都会被弱化，并在块中强化一次。这种方式，因为我们不再有强大的引用，如果他们变得过时，我们等待
NSOperation开始，它们可以被释放。以下是关于如何弱化/强化工作的好文章： http： //blog.aceontech.com/post/111694918560/weakifyself-a-more-elegant-solutiontotoI have been getting a strange crash reported by lots of users through HockeyApp with the following stack trace. It seems to have something to do with NSManagedObject being released in a different dispatch queue ... but I don't get any symbolication for where the problem might be. It seems like a memory management issue, but I'm using ARC so not sure how it would over-release an NSManagedObject.
This is the crash report I get (the main thread shows different traces at different times):
Code Type: ARM-64 Parent Process: launchd [1] Date/Time: 2014-05-12T05:43:54Z OS Version: iPhone OS 7.0.6 (11B651) Report Version: 104 Exception Type: SIGSEGV Exception Codes: SEGV_ACCERR at 0x1c3dbeb8 Crashed Thread: 2 Application Specific Information: objc_msgSend() selector name: _queueForDealloc: Thread 0: 0 CoreFoundation 0x000000018e384618 CFNumberGetType + 0 1 CoreFoundation 0x000000018e3333b8 _CFAppendXML0 + 2768 2 CoreFoundation 0x000000018e333304 _CFAppendXML0 + 2588 3 CoreFoundation 0x000000018e332268 _CFPropertyListCreateXMLData + 196 4 Foundation 0x000000018ef152f4 -[NSDictionary(NSDictionary) writeToFile:atomically:] + 232 5 SimpleList 0x00000001001ae48c __55-[SharedSettingController writeToContactsReferenceFile]_block_invoke (SharedSettingController.m:620) 6 libdispatch.dylib 0x000000019a974420 _dispatch_call_block_and_release + 20 7 libdispatch.dylib 0x000000019a9743e0 _dispatch_client_callout + 12 8 libdispatch.dylib 0x000000019a97756c _dispatch_main_queue_callback_4CF + 340 9 CoreFoundation 0x000000018e3e6d64 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8 10 CoreFoundation 0x000000018e3e50a4 __CFRunLoopRun + 1448 11 CoreFoundation 0x000000018e325b38 CFRunLoopRunSpecific + 448 12 GraphicsServices 0x0000000193d4b830 GSEventRunModal + 164 13 UIKit 0x00000001913640e8 UIApplicationMain + 1152 14 SimpleList 0x000000010006347c _mh_execute_header (main.m:18) 15 libdyld.dylib 0x000000019a98faa0 start + 0 Thread 1: 0 libsystem_kernel.dylib 0x000000019aa71ac8 kevent64 + 8 1 libdispatch.dylib 0x000000019a975d78 _dispatch_mgr_thread + 48 Thread 2 Crashed: 0 libobjc.A.dylib 0x000000019a39f9d0 objc_msgSend + 16 1 CoreData 0x000000018e13b284 -[NSManagedObject release] + 168 2 CoreData 0x000000018e131154 -[_PFArray dealloc] + 96 3 libobjc.A.dylib 0x000000019a3a13d4 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 520 4 libdispatch.dylib 0x000000019a97b428 _dispatch_root_queue_drain + 440 5 libdispatch.dylib 0x000000019a97b638 _dispatch_worker_thread2 + 72 6 libsystem_pthread.dylib 0x000000019ab09918 _pthread_wqthread + 352 7 libsystem_pthread.dylib 0x000000019ab097a8 start_wqthread + 0 Thread 3: 0 libsystem_kernel.dylib 0x000000019aa71cc0 mach_msg_trap + 8 1 CoreFoundation 0x000000018e3e6cac __CFRunLoopServiceMachPort + 180 2 CoreFoundation 0x000000018e3e4e3c __CFRunLoopRun + 832 3 CoreFoundation 0x000000018e325b38 CFRunLoopRunSpecific + 448 4 Foundation 0x000000018ef127fc +[NSURLConnection(Loader) _resourceLoadLoop:] + 344 5 Foundation 0x000000018efa0770 __NSThread__main__ + 996 6 libsystem_pthread.dylib 0x000000019ab0c1b0 _pthread_body + 164 7 libsystem_pthread.dylib 0x000000019ab0c108 _pthread_start + 136 8 libsystem_pthread.dylib 0x000000019ab097b0 thread_start + 0 Thread 4: 0 libsystem_kernel.dylib 0x000000019aa8a76c __select + 8 1 libsystem_pthread.dylib 0x000000019ab0c1b0 _pthread_body + 164 2 libsystem_pthread.dylib 0x000000019ab0c108 _pthread_start + 136 3 libsystem_pthread.dylib 0x000000019ab097b0 thread_start + 0 Thread 5: 0 libsystem_kernel.dylib 0x000000019aa8ae74 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x000000019ab097a8 start_wqthread + 0 Thread 6: 0 libsystem_kernel.dylib 0x000000019aa8ae74 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x000000019ab097a8 start_wqthread + 0 Thread 7: 0 libsystem_kernel.dylib 0x000000019aa8ae74 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x000000019ab097a8 start_wqthread + 0 Thread 2 crashed with ARM-64 Thread State: pc: 0x000000019a39f9d0 fp: 0x0000000102b479c0 sp: 0x0000000102b479a0 x0: 0x00000001782451f0 x1: 0x000000018e2eeb56 x2: 0x00000001705336a0 x3: 0x000000019aac3d18 x4: 0x0000000000000001 x5: 0x0000000000000010 x6: 0x000000017013f900 x7: 0x0000000000000000 x8: 0x000000019ad5bdb8 x9: 0x000000001c3dbea8 x10: 0x0000000000000000 x11: 0x000000230000003f x12: 0x000000014f073410 x13: 0xbadd5bcc1c3dbead x14: 0xffffffffffffffff x15: 0x0000000000000001 x16: 0x000000019a39f9c0 x17: 0x000000018e13b1d8 x18: 0x0000000000000000 x19: 0x00000001705336a0 x20: 0x000000019ad7b000 x21: 0x000000019adc9200 x22: 0x000000019ad7b000 x23: 0x0000000000000715 x24: 0x0000000000000010 x25: 0x0000000102a64038 x26: 0xa3a3a3a3a3a3a3a3 x27: 0x0000000000000001 x28: 0x0000000000000000 lr: 0x000000018e13b284 cpsr: 0x0000000020000000At launch, I do initiate a couple of dispatch queues to do some background work (they use a separate MOC to load managed objects and process them), so those might be responsible, but the queues are labelled in my app, and the stack trace doesn't seem to show which queue is responsible (if it is my own queues). I've run the app with NSZombies enabled but that doesn't help. I have also ran the static analysis tool, and that doesn't turn up anything.
Any ideas what might be causing this problem, and what I can do to debug it?
EDIT:
I'm pretty sure I can isolate the problem area down to a piece of code that gets called after launching the app:
SLAppDelegate *delegate = (SLAppDelegate *) [[UIApplication sharedApplication] delegate]; dispatch_async(delegate.coreDataController.filterMainQueue, ^{ NSManagedObjectContext *backgroundContextImage = [[NSManagedObjectContext alloc] init]; [backgroundContextImage setPersistentStoreCoordinator: delegate.coreDataController.persistentStoreCoordinator]; NSArray *items = [Person getAllPersonsWithContext: backgroundContextImage]; // possibly update some of the items dispatch_async(dispatch_get_main_queue(), ^{ // writes the file inside another dispatch_asyn(dispatch_get_main_queue) [[SharedSettingController sharedSettings] writeToContactsReferenceFile]; }; });I'm just not sure what is wrong with this. It works fine 99% of the time. But that 1% is causing a few crashes that I'd love to get resolved.
解决方案We hit into a a similar issue when using a private managed object context inside an
NSOperationand we ended up working around it by weakifying any parameters and using a private@autoreleasepool. I'll elaborate further below.Our current set up has an
NSOperationQueuewhich has a long running calculation we do in the background. The operation first creates a private managed object context with the parent set as the main object context and goes and fetches its objects.In the mean time, we have a separate
NSOperationQueueelsewhere that syncs down new data from our server, potentially adding, updating, or removing objects used by our calculation operation.We first saw a bunch of these crashes out in the wild and the only way to repro it locally is to have both calculation and sync operations run continuously and after 5-10 minutes, we would see a crash similar to one of the below:
Thread : Crashed: background queue :: NSOperation 0x18f43c90 0 libobjc.A.dylib 0x36f11f46 objc_msgSend + 5 1 CoreData 0x2928408f -[NSManagedObject release] + 166 2 CoreData 0x2927b4d7 -[_PFArray dealloc] + 94 3 libobjc.A.dylib 0x36f201a9 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 404 4 CoreFoundation 0x294713a9 _CFAutoreleasePoolPop + 16 5 Foundation 0x2a1b6453 -[__NSOperationInternal _start:] + 1058 6 Foundation 0x2a25b44b __NSOQSchedule_f + 186 7 libdispatch.dylib 0x3746d651 _dispatch_queue_drain + 952 8 libdispatch.dylib 0x3746809d _dispatch_queue_invoke + 84 9 libdispatch.dylib 0x3746eba1 _dispatch_root_queue_drain + 320 10 libdispatch.dylib 0x3746fcd7 _dispatch_worker_thread3 + 94 11 libsystem_pthread.dylib 0x375c6e31 _pthread_wqthread + 668 Thread : Crashed: background queue :: NSOperation 0x1db59e80 0 libsystem_kernel.dylib 0x3722edfc __pthread_kill + 8 1 libsystem_pthread.dylib 0x372acd37 pthread_kill + 62 2 libsystem_c.dylib 0x371ce909 abort + 76 3 libsystem_malloc.dylib 0x37258331 szone_size 4 libobjc.A.dylib 0x36bf1621 object_dispose + 20 5 CoreData 0x28ec571d -[_PFManagedObjectReferenceQueue dealloc] + 80 6 CoreData 0x28e5630f -[NSManagedObject dealloc] + 166 7 CoreData 0x28e55217 -[_PFManagedObjectReferenceQueue _queueForDealloc:] + 246 8 CoreData 0x28e5508f -[NSManagedObject release] + 166 9 CoreData 0x28e4c4d7 -[_PFArray dealloc] + 94 10 libobjc.A.dylib 0x36c031a9 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 404 11 CoreFoundation 0x29042149 _CFAutoreleasePoolPop + 16 12 Foundation 0x29d88c23 -[__NSOperationInternal _start:] + 1058 13 Foundation 0x29e2dc1b __NSOQSchedule_f + 186 14 libdispatch.dylib 0x371505b1 _dispatch_queue_drain + 952 15 libdispatch.dylib 0x3714af85 _dispatch_queue_invoke + 84 16 libdispatch.dylib 0x37151b9b _dispatch_root_queue_drain + 338 17 libdispatch.dylib 0x37152cd7 _dispatch_worker_thread3 + 94 18 libsystem_pthread.dylib 0x372a9e31 _pthread_wqthread + 668 Thread : Crashed: NSOperationQueue Serial Queue 0 libsystem_kernel.dylib 0x396871f0 __pthread_kill + 8 1 libsystem_pthread.dylib 0x396ef7b7 pthread_kill + 58 2 libsystem_c.dylib 0x39637ff9 abort + 76 3 libsystem_malloc.dylib 0x396aed25 szone_size 4 libobjc.A.dylib 0x390d93a9 object_dispose + 20 5 CoreData 0x2e3d4081 -[_PFManagedObjectReferenceQueue dealloc] + 80 6 CoreData 0x2e3655b7 -[NSManagedObject dealloc] + 166 7 CoreData 0x2e364501 -[_PFManagedObjectReferenceQueue _queueForDealloc:] + 244 8 CoreData 0x2e36437d -[NSManagedObject release] + 164 9 CoreData 0x2e35b867 -[_PFArray dealloc] + 94 10 libobjc.A.dylib 0x390e20d3 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 358 11 CoreFoundation 0x2e5294c1 _CFAutoreleasePoolPop + 16 12 Foundation 0x2ef29999 -[__NSOperationInternal _start:] + 1064 13 Foundation 0x2efcd745 __NSOQSchedule_f + 60 14 libdispatch.dylib 0x395c0cbd _dispatch_queue_drain + 488 15 libdispatch.dylib 0x395bdc6f _dispatch_queue_invoke + 42 16 libdispatch.dylib 0x395c15f1 _dispatch_root_queue_drain + 76 17 libdispatch.dylib 0x395c18dd _dispatch_worker_thread2 + 56 18 libsystem_pthread.dylib 0x396ecc17 _pthread_wqthread + 298We reviewed the code multiple times and was not able to determine why it was crashing. We tried enabling NSZombies, but would run out of memory long before we could get a repro.
What we ended up doing is the following 2 things:
@autoreleasepool
Inside our
[privateObjectContext performBlockAndWait:^{…}]which resides inside ourNSOperationBlock, we wrapped all the code inside an@autoreleasepool{…}. That way all NSManagedObjects retrieved during that block of code will be mark for release before leaving the performBlockAndWait.weakify/strongify
Any parameters that include NSManagedObjects were weakify before passing it into the block, and strongify once in the block. This way since we no longer have a strong reference to them, they can be released if they become out of date while we wait for the
NSOperationto start. Here's a good article on how weakify/strongify works: http://blog.aceontech.com/post/111694918560/weakifyself-a-more-elegant-solution-to这篇关于Crash with NSManagedObject release：“objc_msgSend（）selector name：_queueForDealloc”的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
