1

I keep getting a crash that I'm at a loss to debug. It appears to happen occasionally after deleting Core Data Objects. I delete in different thread/context and merge back to the main context on the main thread. It's rare, I can't reproduce it consistently, and the stack trace is completely useless. This is not a migration issus like other mentions of _Unwind_SjLj_Resume.

From googling around, _Unwind_SjLj_Resume is unwinding an exception. So The story I've made up is I'm crashing with some exception and this error occurs when the exception gets un-wound... Any thoughts on how to proceed?

#0  0x33bd52d4 in __kill ()
#1  0x33bd52ca in kill ()
#2  0x33bd52bc in raise ()
#3  0x33be9d78 in abort ()
#4  0x33bd7986 in __assert_rtn ()
#5  0x32acab56 in _Unwind_SjLj_Resume ()
#6  0x33a47d56 in CFRunLoopRunSpecific ()
#7  0x33a47b8e in CFRunLoopRunInMode ()
#8  0x33b0e4aa in GSEventRunModal ()
#9  0x33b0e556 in GSEventRun ()
#10 0x32099328 in -[UIApplication _run] ()
#11 0x32096e92 in UIApplicationMain ()
Dan J
  • 16,319
  • 7
  • 50
  • 82
Brian King
  • 2,834
  • 1
  • 27
  • 26

4 Answers4

0

If you are doing multiple threads, make sure you are locking your persistent store.

It should look similar to this:

[self.persistentStoreCoordinator lock];
NSManagedObjectContext *context = //your store;
[context save:&error];

if (error)
    // handle error

[self.persistentStoreCoordinator unlock];
amattn
  • 10,045
  • 1
  • 36
  • 33
  • This isn't the problem, the persistent store will be locked by the contexts. Simply using a separate context per thread, as documented by Apple, is fine. – paulbailey Apr 01 '11 at 11:32
  • @paulbailey At least one context per thread is the fine. But I can guarantee that you need to lock your store when using multiple contexts. You will get intermittent crashes otherwise. – amattn Apr 01 '11 at 15:52
  • I don't think the lock will help. I can try, but from the documentation: "There is no typically no need to use locks with managed object or managed object contexts. However, if you use a single persistent store coordinator shared by multiple contexts and want to perform operations on it (for example, if you want to add a new store), or if you want to aggregate a number of operations in one context together as if a virtual single transaction, you should lock the persistent store coordinator." – Brian King Apr 08 '11 at 19:03
0

You might look at this posting. I was experiencing something very similar and was able to track down the cause to a reference to a released object (one that on which dealloc had already been called). As with your case, I was deleting NSManagedObjects. Turning on "Stop on Objective-C Exceptions" allowed me to trap the exception.

Community
  • 1
  • 1
westsider
  • 4,967
  • 5
  • 36
  • 51
0

Turns out It was due to an error in my didSave - isDeleted. I was dispatching file deletion using NSFileManager defaultManager which is not thread safe. There was no sign of it in my stack traces but I tracked it down by stepping through assembler on the save routine and noticed that the runloop_handle_dispatch function was the last to operate and deduced from there.

Thanks for your help, Bleh!

Brian King
  • 2,834
  • 1
  • 27
  • 26
0

For anyone researching this in the future I received this exception and the cause was because I had set a cache name in the FetchedResltsController - the cache was trying to load a row which had been deleted from the database - perhaps the app quit during the delete process. anyways setting the cacheName to nil on the call to initWithFetchRequest sorted my problems.

Grouchal
  • 9,756
  • 6
  • 34
  • 46