NSManagedObjectContext save leads to _thereIsNoSadnessLikeTheDeathOfOptimism

Question

Created Sep ’24

Replies 3

Boosts 0

Participants 2

I have been investigating a crash where saving a context leads to a crash triggered internally by Core Data. Is there any information on what exception or fatal error it is? Or any hint of any kind which leads to NSManagedObjectContext.m:1475 (seems like this line calls abort or some sort of fatal error). Seems like this happens when the app is in background.

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x000000019266a3f8
Termination Reason: SIGNAL 5 Trace/BPT trap: 5
Terminating Process: exc handler [38173]

Triggered by Thread:  9

…

Thread 9 Crashed:
0   CoreData                      	0x000000019266a3f8 -[NSManagedObjectContext _thereIsNoSadnessLikeTheDeathOfOptimism] + 36 (NSManagedObjectContext.m:1475)
1   CoreData                      	0x00000001925c8fa0 -[NSManagedObjectContext save:] + 1844 (NSManagedObjectContext.m:1688)
2   MyApp                       	0x0000000102cc747c closure #1 in DatabaseContainer.write(_:completion:) (in MyApp) (DatabaseContainer.swift:233) + 7861372
3   MyApp                       	0x0000000102baab14 thunk for @escaping @callee_guaranteed () -> () (in MyApp) (<compiler-generated>:0) + 6695700
4   CoreData                      	0x000000019252dfe8 developerSubmittedBlockToNSManagedObjectContextPerform + 156 (NSManagedObjectContext.m:3985)
5   libdispatch.dylib             	0x00000001922e2dd4 _dispatch_client_callout + 20 (object.m:576)
6   libdispatch.dylib             	0x00000001922ea400 _dispatch_lane_serial_drain + 748 (queue.c:3900)
7   libdispatch.dylib             	0x00000001922eaf30 _dispatch_lane_invoke + 380 (queue.c:3991)
8   libdispatch.dylib             	0x00000001922f5cb4 _dispatch_root_queue_drain_deferred_wlh + 288 (queue.c:6998)
9   libdispatch.dylib             	0x00000001922f5528 _dispatch_workloop_worker_thread + 404 (queue.c:6592)
10  libsystem_pthread.dylib       	0x00000001e6e8c934 _pthread_wqthread + 288 (pthread.c:2696)
11  libsystem_pthread.dylib       	0x00000001e6e890cc start_wqthread + 8 (:-1)

Boost

Answer 1

DTS Engineer OP

Apple

Sep ’24

_thereIsNoSadnessLikeTheDeathOfOptimism can be triggered when Core Data detects a constraint conflict in the saving process and fails to resolve it. The way to address this kind of issue is to figure out the conflict and try to avoid that.

If you can reproduce the issue in your Xcode build, you can probably find conflict list from your Xcode console, which provides more details about the conflicted constraint and objects, like below:

CoreData: error: failed to resolve optimistic locking failure: constraint validation failure with {
NSExceptionOmitCallstacks = 1;
conflictList = (
"NSConstraintConflict (...) for constraint (\n ...\n): database: (null), conflictedObjects: (\n \"... \",\n \"... \"\n)",
);
}

Otherwise, you might consider gathering a sysdiagnose and find the relevant log from there.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

0

Answer 2

laevandus OP

Sep ’24

Thank you for quick response. I'll review constraints. The model has id property constraints for many entities so it has to be that. Unfortunately I haven't managed to reproduce this myself and don't have the detailed error log available.

0

Answer 3

laevandus OP

Sep ’24

Currently I am using a fixed number of NSManagedObjectContext objects: 1 for writing, 2 for reading. All of them are background contexts created with newBackgroundContext() method and merge policy is set to NSMergeByPropertyObjectTrumpMergePolicy. Based on this setup, it seems like CoreData should always be able to resolve unique constraints when data is being inserted. I wonder, if this failure could be avoided by using a custom merge policy? It feels like based on my setup CoreData implies that such unique constraints issue should not happen and that is why it leads to a crash.

0