Debugging SIGABRT within NSManagedObjectContext -save:

Question

From inside NSManagedObjectContext -save: I am getting this message:

Assertion failed: (_Unwind_SjLj_Resume() can't return), function _Unwind_SjLj_Resume, file /SourceCache/libunwind/libunwind-24.1/src/Unwind-sjlj.c, line 326.

Program received signal: “SIGABRT”.

warning: Unable to read symbols for /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2.1 (8C148)/Symbols/Developer/usr/lib/libXcodeDebuggerSupport.dylib (file not found).

This happens when I delete an Experiment object with to-many with Run which has to-many with Sample which has to-one with Data. Experiment also has to-many with Page which has to-many with Display which has to-many to Run. I mention this to point out the cyclical nature of the graph. Here is a simplified graph of model:

An Experiment a top level entity with which the user interacts. An Experiment contains multiple Run objects. A Run is a collection of data starting at a particular time and ending at a later time. Since data can be collected from multiple sources simultaneously, there is a Sample for each source for each Run. An Experiment contains data and this data needs to be viewed and interacted with. So, each Experiment has some number of Page objects and each Page contains some number of Displays (e.g., graphs, meters). A Display is configured to display some subset of the Runs that belong to the Experiment. So, while an Experiment may contains dozens of Runs, one of its Pages will only display a few of those Runs at a time. The Display entity maintains this list. A Display is not a view. A view will reference a Display object and be notified of changes to the Display object.

I had been using Delete Rules but have now switched to "No Action" delete rules in combination with -prepareForDeletion methods for all of these classes. This change made no difference. In both cases, the error message is the same.

Interestingly, when I relaunch the app, all the objects that were marked for deletion have been deleted.

Also, if an Experiment has no Run objects, then deletion works without incidence. For that matter, deleting a single Run from an Experiment also works.

I am hoping that someone has seen something like this and can offer advice on what would cause this. Or, if someone has advice on how to get libXcodeDebuggerSupport.dylib for iOS 4.2.1, that might also be helpful.

Update: I followed advice found here and was able to get Xcode to find libXcodeDebuggerSupport.dylib for iOS 4.2.1. But this did not help at all in diagnosing problem - which persists.

Update 2: After reading a bit and downloading a version of unwind-sjlj.c, it seems that I am dealing with something like an uncaught exception. I am not sure how this helps me...

Update 3: Thanks to Kamchatka, I did something I probably should have done a few days ago: turned on "Stop on Objective-C Exceptions". This allowed me to see that a reference to a deleted object was still being held - and, worse, was key-value observing the deleted object. Fixing this fixed problem and I was able to revert to using delete rules rather than -prepareForDeletion methods.

Khalid

What was your original delete rule? Cascasde all the way down to the data level? Is there a reason that Display has direct access to the Runs instead of going through the Page/Experiment tree? – Mcpherson

Update Xcode to 3.2.5 to get rid of the debugger warning. Your Device is 4.2.1 which requires up to date debug symbols of 3.2.5 – Rhapsodist

@Michael: Display manages the Runs that are displayed for a specific page, so that would always be a subset of Runs contained by an Experiment. There could be several Pages for a particular Experiment, each with multiple Displays and each Display showing a set of Runs. I hope that this makes sense. – Khalid

@Martin: I am running Xcode 3.2.5 but I am curious if there is something that I could do to it (settings?) that would enabled some additional functionality. – Khalid

Sort of makes sense... :-) It does sound a bit like you've got visual display logic (Page/Display) mixed with your data logic. I have no idea if this is causing the problem - but it is creating the circular chain. – Mcpherson

@Michael: I am confident that it makes sense but it might take a bit of writing to convince other reasonable people ;-). I had suspected the circular chain - but I have set all relationships to be optional and now the delete rules are almost all either No Action or Nullify. I have found some interesting bugs in my code but nothing that, once fixed, makes a difference. – Khalid

@Khalid did you solve this issue? I'm encountering the same problem. – Tierza

Answer 1

You should try to activate "Run > Stop on Objective-C exception". It allowed me to find the place where there was an access to an object turned into fault which was the root cause of the problem.

Tierza

Following this advice, I was able to track down the cause of my crashes. I had some KVO code that was referencing a deleted object, and this code was firing during the deletion process. So, ultimately, the problem was in a -dealloc method. – Khalid

Where is this setting in XCode4? – Roydd

@tomwhipple: See stackoverflow.com/questions/4961770/… – Minnich