Сбой данных ядра NSInternalInconsistencyException 'все еще активен'

У меня есть два контекста управляемых объектов, которые имеют один и тот же постоянный координатор хранилища:

Один с NSMainQueueConcurrencyType для основного потока и
Тот, что NSPrivateQueueConcurrencyType для выполнения фоновой обработки.

Все операции синтаксического анализа данных выполняются в вызовах executeBlock против частной очереди и объединяются через NSManagedObjectContextDidSaveNotification для обновлений пользовательского интерфейса в основном потоке.

У меня есть утверждения многопоточности данных ядра, и они никогда не запускаются при возникновении сбоя.

Иногда я получаю сообщение об ошибке statement is still active, когда я нажимаю новое представление с NSFetchedResultsController, пока работает фоновый контекст. Авария либо вызывается на выборку для выбранного контроллера результатов, либо в коде, который хранит данные. Когда он выходит из строя в разделе анализа данных, он всегда терпит неудачу при соединении со многими.

Эти сбои составляют 100% iOS 8, и я никогда не видел их на 7.

Мой вопрос таков:, предполагая, что я не нарушаю ограничение по контенту (которое должно звучать громко, и не...) есть ли что-то еще очевидное, что я мог бы делать что приведет к тому, что контекст основного потока будет запущен, когда фоновый поток находится в процессе работы в постоянном хранилище?

Вот что говорит Crashlytics:

Thread : Fatal Exception: NSInternalInconsistencyException
0  CoreFoundation                 0x00000001871e659c __exceptionPreprocess + 132
1  libobjc.A.dylib                0x00000001978f00e4 objc_exception_throw + 60
2  CoreData                       0x0000000186e97c6c -[NSSQLiteStatement cachedSQLiteStatement]
3  CoreData                       0x0000000186e9739c -[NSSQLiteConnection prepareSQLStatement:] + 76
4  CoreData                       0x0000000186eb3810 -[NSSQLChannel selectRowsWithCachedStatement:] + 76
5  CoreData                       0x0000000186f9e7a4 newFetchedRowsForFetchPlan_MT + 1100
6  CoreData                       0x0000000186ecf948 -[NSSQLCore newFetchedPKsForSourceID:andRelationship:] + 2120
7  CoreData                       0x0000000186ecea24 -[NSSQLCore newValueForRelationship:forObjectWithID:withContext:error:] + 616
8  CoreData                       0x0000000186f67480 __110-[NSPersistentStoreCoordinator(_NSInternalMethods) newValueForRelationship:forObjectWithID:withContext:error:]_block_invoke + 80
9  CoreData                       0x0000000186f6d654 gutsOfBlockToNSPersistentStoreCoordinatorPerform + 180
10 CoreData                       0x0000000186f60ccc _perform + 204
11 CoreData                       0x0000000186ece730 -[NSPersistentStoreCoordinator(_NSInternalMethods) newValueForRelationship:forObjectWithID:withContext:error:] + 160
12 CoreData                       0x0000000186ece4d8 -[NSFaultHandler retainedFulfillAggregateFaultForObject:andRelationship:withContext:] + 716
13 CoreData                       0x0000000186ef15ec -[_NSFaultingMutableSet willReadWithContents:] + 444
14 CoreData                       0x0000000186ed146c -[_NSFaultingMutableSet count] + 32
15 CoreData                       0x0000000186ecd234 -[NSManagedObject(_NSInternalMethods) _didChangeValue:forRelationship:named:withInverse:] + 440
16 Foundation                     0x0000000187fe1a14 NSKeyValueNotifyObserver + 340
17 Foundation                     0x0000000187fe1534 NSKeyValueDidChange + 460
18 Foundation                     0x0000000187fcaac4 -[NSObject(NSKeyValueObserverNotification) didChangeValueForKey:] + 116
19 CoreData                       0x0000000186ec4e90 _PF_ManagedObject_DidChangeValueForKeyIndex + 140
20 CoreData                       0x0000000186ec3248 _sharedIMPL_setvfk_core + 284
21 My App                     0x00000001000f0b00 -[LocationAdapter processBuildingList:context:completion:] (LocationAdapter.m:134)

Ответ 1

Я закончил тем, что создал основной стек данных, и это исчезло. Перемещение в постоянный контекст хранилища, контекст дочернего интерфейса и фон фонового изображения внука и постоянная цепочка, соответственно, сделали все это лучше. Я все еще не уверен на 100%, почему исходная настройка не работала с 8.

Ответ 2

Вы можете использовать копию контекста nsmanaged object в качестве нового экземпляра контекста nsmanagedobject. Для каждого контекста управляемого объекта вы должны использовать это так, чтобы сохранить несогласованность в многопоточности

[backgroundMOC performBlockAndWait:^{
    // read/write operation
    [backgroundMOC saveContextWithMOC:backgroundMOC];
}];

//Основная тема MOC

[mainMOC performBlockAndWait:^{
    // read/write operation
    [backgroundMOC saveContextWithMOC:backgroundMOC];
}];