Более чем вероятно, что это проблема потоков, так или иначе. В этом вопросе недостаточно информации, чтобы убедиться в этом, но стоит проверить журналы сбоев и посмотреть трассировку стека для всех потоков во время исключения, а также посмотреть, делают ли другие потоки что-нибудь, что взаимодействует. с управляемым объектом. Возможно, у вас есть обработчик уведомлений, обработчик завершения соединения URL или какой-то другой фрагмент кода с использованием параллелизма, который вы не заметили, с использованием основных объектов данных в фоновом режиме. Стоит отметить, что установка или доступ к любому свойству любого управляемого объекта из контекста, который используется более чем в одном потоке, потенциально может вызвать такого рода исключения, что может затруднить диагностику.
Относительно простое решение этих проблем в большинстве приложений состоит в том, чтобы передать выполнение этого кода в основной поток (используя dispatch_async()). В качестве альтернативы, если у вас есть много обработки, может быть лучше создать дочерний контекст в фоновом потоке и повторно извлечь объект из дочернего контекста, а затем сохранить дочерний контекст. Конечно, для повторного извлечения объекта вам нужно иметь его objectID, которое является свойством, доступ к которому можно получить только в потоке, в который объект был первоначально извлечен…