Saving NSManagedObjectContext is not a failure, but a break at objc_exception_throw

Question

I have the same problem described at this address http://www.cocoabuilder.com/archive/cocoa/288659-iphone-nsmanagedobjectcontext-save-doesn-crash-but-breaks-on-objc-exception-throw.html

I am debugging an application that uses Core Data with a multi-threaded process, and I have a breakpoint at objc_exception_throw and it hits that breakpoint in a save call. (line 2 in code)

NSError *error = nil; [self.managedObjectContext save:&error]; if (error) { NSLog(@"Error : %@",error); } 

I have nothing that is logged. I am using Xcode 4 with ios 4.0 -> 4.3. I think this is not related to the Xcode / iOS version.

Answer 1

• First, when using multithreading with CoreData, I had few problems when passing NSManagedObject around the application. Instead, as documented by Apple, I end up passing NSManagedObjectID and restoring the complete object.
• Secondly, if you have nothing registered, this is most likely due to a memory problem, try running the profiler especially, but not only, look for "Zombies", this should tell you more.
• Finally, make sure you initialize the context correctly, I have a similar problem, because the model from the momd file is not found and not loaded.

Answer 2

Looking at this answer , it shows that CoreData uses exceptions to control the flow of its program. This is why the debugger breaks into objc_exception_throw. As far as I know, there is no way to disable this.

EDIT: Since then, there is currently a solution to ignore these exceptions: Ignore some exceptions when using the Xcode All Exceptions breakpoint

BTW: Do not check for error , but use the return value of BOOL to ensure the success of your save call. The correct way to do this is:

 NSError *error = nil; BOOL success = [self.managedObjectContext save:&error]; if (!success) { NSLog(@"Error : %@",error); } 

Answer 3

I had a similar problem, in the end it turned out to be due to the NSManagedObjectContextDidSaveNotification observer, which was released without being removed from the notification center. It seems that the CoreData exception "hides" an unknown selector exception that occurs when the notification center tries to notify any object that takes up memory freed by a registered (but freed) observer.

Answer 4

I happened to meet this problem, and after a long debugging, I found it due to duplicate declaration of the NSError * error, maybe you had another NSError * error in the external area, for example:

 NSError* error = nil; 

Some code

 if (!error) { NSError* error = nil; // your code } 

Then the error will be zero, although in fact there is an exception.

Answer 5

Recently, I ran into the same problem: the application crashes without any kind of log while trying to save managedObjectContext.

In my case, the above was a completely different reason:
Make sure your Mac does not have a database manager that can block persistent data storage.

This (apparently) will also destroy the Core Date stack without throwing any visible errors into the code or into the log.

It turned out that I had some unsaved changes, which caused the database manager to lock the repository. The problem with closing the database manager. A simple and stupid mistake, but it took me hours to understand.