Problems with to-many relationship cascade deletes

[prvnl]

Since I’m using the new master branch (also the with the current develop branch), I’m experiencing two problems with to-many relationships. These problems did not occur when I was using the older Simperium Framework (dated 02-06-2013) and using the same database model and same app version.

Steps to reproduce:

Database model has to-many relationship between ‘Work’ -> ‘WorkActivities’. The relationship is using the Cascade delete rule. The inverse relationship is optional and uses the nullify delete rule.

1. Cascade deletes fail on remote client

1. On device A, create e.g. 10 ‘Work’ objects with related ‘WorkActivities’
2. On device B, just start the app so all objects are synced
3. On device A, start deleting the 10 created objects
4. On device B, observe the crash of the app

1. Weird behavior when removing related to-many objects

1. On device A, create a ‘Work’ object with related ‘WorkActivities’
2. On device B, open the just created object
3. On device B, Delete the related ‘WorkActivities’ from the ‘Work’ object
4. On device B, Save the ‘Work’ object and go back to the list view controller
5. On device B, Now the ‘Work’ object is displayed twice in the list VC

If you need additional logging or something else, just let me know!

Thanks,

Patrick

[jleandroperez]

@prvnl hello there!,

I'll be building a sample app to reproduce the two issues you're experiencing. May i ask you a couple questions?

1. 'Cascade crash' bug:
1.1. What kind of UI are you using in the app? Perhaps a UITableViewController, which pushes a UIViewController when you tap on any row?
1.2. Which view is onscreen when 'Device B' crashes? the root view, or the details view (if you actually use that)?
1.3. Are you using NSFetchedResultsController? if not, are you refreshing the UI when the mainMOC gets saved?
1.4. Would it be possible to get the stack trace when the app crashes?

2. 'Weird Behavior' bug:
2.1. In which device you're performing steps 3 and 4 ? 'Device B' ?
2.2. In which device you're getting a duplicate 'Work' entity? 'Device B' / 'Device A' / Both?
2.3. If you logout / login again, do you get a duplicate entry onscreen?

Thanks in advance!

P.s.: How did you architect your app? is the UI attached to the mainMOC? or you're using a child context?

[prvnl]

Hi @jleandroperez

Thanks for your help!

1. 'Cascade crash' bug: 

   1.1. I’m using a UITableViewController that pushes another UITableViewController that has the details view.
   1.2. For the test on device B, I just start the app, not even loaded/showing the UITableViewControllers
   1.3. I’m using a NSFetchedResultsController
   1.4. Stack trace will follow
2. 'Weird Behavior' bug:
   
2.1. All on device B (I’ve updated the initial issue)
   
2.2. Only on device B and only when I first create the object on device A
   2.3. The duplicate entry is not visible anymore after logout / login

My UI is attached to the main MOC, I using the Core Data code from the AppDelegate of SimpletodoFinal to initialize Core Data

[prvnl]

Hereby the stack trace for 'Cascade crash' bug. As I mentioned before, I just start the app to a menu screen, not even loaded/showing the UITableViewControllers. It seems that the exception is easier to generate when I have more then 1 related to-many objects (e.g. 4 related to-many objects):

2013-11-30 11:59:34.666 TestApp[26866:70b] *** Terminating app due to uncaught exception 'NSObjectInaccessibleException', reason: 'CoreData could not fulfill a fault for '0xc165dc0 x-coredata://FE263BA3-1F38-400C-9EC8-6D02D06C324B/Works/p656''
*** First throw call stack:
(
    0   CoreFoundation                      0x02ad75e4 __exceptionPreprocess + 180
    1   libobjc.A.dylib                     0x0280b8b6 objc_exception_throw + 44
    2   CoreData                            0x024e133b _PFFaultHandlerLookupRow + 2715
    3   CoreData                            0x02513628 -[NSFaultHandler fulfillFault:withContext:] + 40
    4   CoreData                            0x024e4b4f -[NSManagedObject willAccessValueForKey:] + 207
    5   TestApp                             0x000affc7 __44-[SPCoreDataStorage childrenContextDidSave:]_block_invoke + 859
    6   CoreData                            0x02515fef developerSubmittedBlockToNSManagedObjectContextPerform + 95
    7   libdispatch.dylib                   0x034854b0 _dispatch_client_callout + 14
    8   libdispatch.dylib                   0x0347375e _dispatch_main_queue_callback_4CF + 340
    9   CoreFoundation                      0x02b3ca5e __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 14
    10  CoreFoundation                      0x02a7d6bb __CFRunLoopRun + 1963
    11  CoreFoundation                      0x02a7cac3 CFRunLoopRunSpecific + 467
    12  CoreFoundation                      0x02a7c8db CFRunLoopRunInMode + 123
    13  GraphicsServices                    0x0327e9e2 GSEventRunModal + 192
    14  GraphicsServices                    0x0327e809 GSEventRun + 104
    15  UIKit                               0x01217d3b UIApplicationMain + 1225
    16  TestApp                             0x0001d61d main + 141
    17  libdyld.dylib                       0x0371770d start + 1
    18  ???                                 0x00000001 0x0 + 1
)
libc++abi.dylib: terminating with uncaught exception of type _NSCoreDataException

[prvnl]

Hereby another stack trace for 'Cascade crash' bug:

2013-11-30 12:05:46.535 TestApp[26916:1203] *** Terminating app due to uncaught exception 'NSObjectInaccessibleException', reason: 'CoreData could not fulfill a fault for '0xc5ed180 x-coredata://FE263BA3-1F38-400C-9EC8-6D02D06C324B/Works/p638''
*** First throw call stack:
(
    0   CoreFoundation                      0x02ad75e4 __exceptionPreprocess + 180
    1   libobjc.A.dylib                     0x0280b8b6 objc_exception_throw + 44
    2   CoreData                            0x024e133b _PFFaultHandlerLookupRow + 2715
    3   CoreData                            0x02513628 -[NSFaultHandler fulfillFault:withContext:] + 40
    4   CoreData                            0x02587929 -[NSManagedObject(_NSInternalMethods) _updateFromRefreshSnapshot:includingTransients:] + 265
    5   CoreData                            0x0251c0a2 -[NSManagedObjectContext(_NestedContextSupport) _copyChildObject:toParentObject:fromChildContext:] + 994
    6   CoreData                            0x0251b988 -[NSManagedObjectContext(_NestedContextSupport) _parentProcessSaveRequest:inContext:error:] + 1480
    7   CoreData                            0x025941f4 __82-[NSManagedObjectContext(_NestedContextSupport) executeRequest:withContext:error:]_block_invoke + 676
    8   CoreData                            0x02516321 internalBlockToNSManagedObjectContextPerform + 17
    9   libdispatch.dylib                   0x034854b0 _dispatch_client_callout + 14
    10  libdispatch.dylib                   0x034725cf _dispatch_barrier_sync_f_slow + 427
    11  libdispatch.dylib                   0x03472413 dispatch_barrier_sync_f + 74
    12  CoreData                            0x025162a2 _perform + 114
    13  CoreData                            0x0251614e -[NSManagedObjectContext(_NestedContextSupport) executeRequest:withContext:error:] + 238
    14  CoreData                            0x024f0ccc -[NSManagedObjectContext save:] + 764
    15  TestApp                             0x000aefd1 -[SPCoreDataStorage save] + 208
    16  TestApp                             0x000b2712 -[SPChangeProcessor processRemoteDelete:acknowledged:bucket:storage:] + 526
    17  TestApp                             0x000b41c4 -[SPChangeProcessor processRemoteChange:bucket:clientID:] + 1707
    18  TestApp                             0x000b4896 __58-[SPChangeProcessor processRemoteChanges:bucket:clientID:]_block_invoke_2 + 285
    19  libdispatch.dylib                   0x034707f8 _dispatch_call_block_and_release + 15
    20  libdispatch.dylib                   0x034854b0 _dispatch_client_callout + 14
    21  libdispatch.dylib                   0x0347307f _dispatch_queue_drain + 452
    22  libdispatch.dylib                   0x03472e7a _dispatch_queue_invoke + 128
    23  libdispatch.dylib                   0x03473e1f _dispatch_root_queue_drain + 83
    24  libdispatch.dylib                   0x03474137 _dispatch_worker_thread2 + 39
    25  libsystem_pthread.dylib             0x03811dab _pthread_wqthread + 336
    26  libsystem_pthread.dylib             0x03815cce start_wqthread + 30
)
libc++abi.dylib: terminating with uncaught exception of type _NSCoreDataException

[jleandroperez]

@prvnl hello there!. Would you please verify the fix for the cascade crash?. ('Dupes' issue still in the works).

Thanks for the feedback!!

P.s.: By the way, just in case, the patch is in 'develop' branch.

[prvnl]

Hi @jleandroperez

Just tried the fix you committed to the develop branch. My first testing was successful and the crash did not occur. Only after e.g. 100 deletes the crash came back. So in the previous version it took around 10 deletes to reproduce the crash, in the new version it takes a lot longer to reproduce the crash but it's still there...

Hereby the stack trace:

2013-12-04 20:41:24.673 TestApp[10041:70b] *** Terminating app due to uncaught exception 'NSObjectInaccessibleException', reason: 'CoreData could not fulfill a fault for '0xd8bebd0 x-coredata://EBF5CF2F-5FC1-46C1-9B89-7187E0E6E2AB/Works/p1000''
*** First throw call stack:
(
    0   CoreFoundation                      0x02ad75e4 __exceptionPreprocess + 180
    1   libobjc.A.dylib                     0x0280b8b6 objc_exception_throw + 44
    2   CoreData                            0x024e133b _PFFaultHandlerLookupRow + 2715
    3   CoreData                            0x02513628 -[NSFaultHandler fulfillFault:withContext:] + 40
    4   CoreData                            0x024e4b4f -[NSManagedObject willAccessValueForKey:] + 207
    5   TestApp                             0x000afbc7 __44-[SPCoreDataStorage childrenContextDidSave:]_block_invoke + 859
    6   CoreData                            0x02515fef developerSubmittedBlockToNSManagedObjectContextPerform + 95
    7   libdispatch.dylib                   0x034854b0 _dispatch_client_callout + 14
    8   libdispatch.dylib                   0x0347375e _dispatch_main_queue_callback_4CF + 340
    9   CoreFoundation                      0x02b3ca5e __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 14
    10  CoreFoundation                      0x02a7d6bb __CFRunLoopRun + 1963
    11  CoreFoundation                      0x02a7cac3 CFRunLoopRunSpecific + 467
    12  CoreFoundation                      0x02a7c8db CFRunLoopRunInMode + 123
    13  GraphicsServices                    0x0327e9e2 GSEventRunModal + 192
    14  GraphicsServices                    0x0327e809 GSEventRun + 104
    15  UIKit                               0x01217d3b UIApplicationMain + 1225
    16  TestApp                             0x0001d21d main + 141
    17  libdyld.dylib                       0x0371770d start + 1
)
libc++abi.dylib: terminating with uncaught exception of type _NSCoreDataException

Maybe it's not related, but I get a lot of the following logging messages (also after restart of the app). I think this is because the object is already deleted by the cascade:

2013-12-04 20:55:33:787 WorkReg[10883:6413] Simperium error (WorkActivities), received an invalid change for (2cb2ad28dbbd4c3390495e75c0d9d1fa): {
    ccids =     (
        905c1f83d72c45e8a2df4f6d0739c854
    );
    clientid = "ios-7a968ce6bc2f47b0acf6877304fb1498";
    cv = 529f88b6ba5fdc4ed742f29b;
    ev = 2;
    id = 2cb2ad28dbbd4c3390495e75c0d9d1fa;
    o = "-";
}

[jleandroperez]

@prvnl sorry about the delay!. Added unit tests + (both) issues should be fixed now, in develop.

Would it be possible to verify the fix in your end?.

_Thanks_!!!

[prvnl]

Yessss!!! This resolved both issues!

Thanks @jleandroperez for the fix, now I can use the new Simperium version in my apps!

Regards Patrick

[jleandroperez]

@prvnl thanks for the feedback (and again, thanks for reporting this issue)!!

Best,
Jorge