I keep getting crashes from a save: command on a managedObjectContext. It doesn't even fulfill the NSLog statement so I don't see the unresolved error statement, so I can't figure out what the problem might be. It doesn't happen every time, but only sporadically.
Here's the code (which basically wants to increment a counter):
if ([[managedObject valueForKey:#"canSee"]boolValue]){
int read = [[managedObject valueForKey:#"timesRead"] intValue] +1;
[managedObject setValue:[NSNumber numberWithInt:read] forKey:#"timesRead"];
NSError *error;
if (![resultsController.managedObjectContext save:&error]) { //<-- crashes on this line!
NSLog(#"Unresolved Core Data Save error %#, %#", error, [error userInfo]);
exit(-1);
}
In the console window I get messages like this:
2010-08-20 08:12:20.594 AppName[23501:207] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFSet controllerWillChangeContent:]: unrecognized selector sent to instance 0xe54f560'
or this:
2010-08-20 08:12:20.594 AppName[23501:207] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFSet controllerWillChangeContent:]: unrecognized selector sent to instance 0xe54f560'
or even this:
2010-08-19 23:09:59.337 AppName[761:307] Serious application error. Exception was caught during Core Data change processing. This is usually a bug within an observer of NSManagedObjectContextObjectsDidChangeNotification. -[UITableViewLabel controllerWillChangeContent:]: unrecognized selector sent to instance 0x7f0a860 with userInfo (null)
2010-08-19 23:09:59.356 AppName[761:307] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UITableViewLabel controllerWillChangeContent:]: unrecognized selector sent to instance 0x7f0a860'
Then it shows the call stack at first throw, followed by a notice (terminate called after throwing an instance of 'NSException', '[Switching to process 23501]' and 'Program received signal: “SIGABRT”.'
I think the problem has something to do with CoreData but I'm not sure. I've cleaned my build and targets and it doesn't seem to help. I've tried locking/unlocking the ManagedObjectContext and it doesn't help.
Any ideas here on where to start to look for a resolution would be greatly appreciated!
Looks like you are releasing a UIViewController and not releasing its associated NSFetchedResultsController. The NSFetchedResultsController is trying to notify its delegate (most likely your UIViewController) of the save on exit.
To elaborate on Marcus' answer, you need to make sure you nil out the delegate for your NSFetchedResultsController when your view disappears:
- (void)viewWillDisappear:(BOOL)animated
{
[super viewWillDisappear:animated];
self.fetchedResultsController.delegate = nil;
}
Related
I know it seems a stupid question, but after modelling the typical master-detail or parent-children relationship in Core Data, I want to create the NSManagedObject subclasses and I realised Core Data code generator is always using strong/retain for the parent properties. Is that right? In a normal object graph that is wrong because we have a retain cycle, but not sure in the Core Data context, because I guess the code generator should generate the code properly. Thanks for suggestions.
After trying to use weak properties in my NSManagedObject subclasses, I receive:
2016-03-15 11:57:36.921 WWWWW[84639:1153803] CoreData: error: Property 'company' is marked __weak on class 'Package'. Cannot generate a setter method for it.
2016-03-15 11:57:36.921 WWWW[84639:1153803] -[Package setCompany:]: unrecognized selector sent to instance 0x7f97917068e0
2016-03-15 11:57:36.933 WWWW[84639:1153803] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[Package setCompany:]: unrecognized selector sent to instance 0x7f97917068e0'
We have a number of sections of code in the format:
try
{
// code
}
catch(std::exception &e)
{
// log exception
}
catch(...)
{
// log unknown exception.
}
Every so often, the unknown exception code triggers, and logs an unknown exception.
I always thought that all exceptions were meant to derive from std::exception, and thus catching std::exception would catch all exceptions.
Is there some other exception that I should be catching?
If my code ends up in the unknown exception handler, is there any way that I can find out what exception was actually caught?
edit
We managed to locate the cause of the problem- despite saying that they had, the customer had not installed .NET 3.5, which our code depends on, and the system fell over when trying to use the XML parser.
Is there some other exception that I should be catching?
This depends on your code. Libraries you call can throw exceptions not derived from std::exception, examples are MFC's CException or Microsoft's _com_error. Also, an access violation might be catched by catch(...), which is the reason why I would not use catch(...) in my code - it's just to broad for me.
2.If my code ends up in the unknown exception handler, is there any way that I can find out what exception was actually caught?
You can run your code in the debugger and configure the debugger to break your program when the exception is thrown (first chance). Then you know exactly which line of code triggers the exception and should be able to see what exactly is thrown.
In my APP I have a really simple model with just two classes. One of those is CDAttribute.
This APP is in the store and was working. Now I tested it the fist time with xCode 6 today and put a new version of it on my iPad. Now I get this error
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '"CDAttribute" is not a subclass of NSManagedObject.'
*** First throw call stack:
(0x18342e084 0x193e800e4 0x1830f5350 0x183113f94 0x10004450c 0x100043410 0x1833d4434 0x1833137e0 0x18420b6c0 0x10003f758 0x187e3f104 0x187e432dc 0x187e47624 0x187e46b00 0x187e46a58 0x187e3a38c 0x18b605640 0x1833e6360 0x1833e5468 0x1833e3a8c 0x183311664 0x18c41f5a4 0x187c16984 0x10004d0a0 0x1944eea08)
libc++abi.dylib: terminating with uncaught exception of type NSException
calling this fuction
CDAttribute *attr = (CDAttribute *)[NSEntityDescription insertNewObjectForEntityForName:#"CDAttribute" inManagedObjectContext:self.managedObjectContext];
Which I can't understand because I didn't touch the model nor the code.
It seems like CDAttribute is reserved in iOS8. I changed the Classname (not the table name in the model, because then I'd probably loose all my entries when I update to this version) to SIAttribute and it worked.
It was the solution, however I'd be intrested if its really reserved and where it is documented.
thanks for reading. We've recieved crash reports on our iOS app with the following error:
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'This NSPersistentStoreCoordinator has no persistent stores. It cannot perform a save operation.'
This occurs when our main queue NSManagedObjectContext attempts to save:
BOOL saved = [managedObjectContext save:&error];
Which occurs in a block submitted via:
[managedObjectContext performBlockAndWait:saveBlock];
The internet (especially SO) is full of explanations for this error suggesting that we never had a persistent store cooridinater (that we failed to create it properly when we built the core data stack). However, it's difficult to see how we could get to this point in program execution without a persistent store coordinator. For kicks, i commented out the line where we set the persistent store and the app crashes almost immediately (without getting to our save method).
Does anyone know if there's an alternate cause for this exception or is it ALWAYS because there is no persistent store? Is there any way to lose a persistent store?
A little more color: we use parent/child NSManagedObjectContexts in order to load data in a background thread. The full save method looks like this:
-(void)saveWithManagedObjectContext:(NSManagedObjectContext*)managedObjectContext successHandler:(void (^)())successHandler failureHandler:(void (^)(NSManagedObjectContext* managedObjectContext, NSError*))failureHandler
{
void(^saveBlock)() = ^() {
NSError *error = nil;
BOOL saved = [managedObjectContext save:&error];
if (!saved) {
if (error != nil) {
NSLog(#"Unresolved error saving %#, %#", error, [error userInfo]);
}
failureHandler(managedObjectContext, error);
} else {
if (managedObjectContext.parentContext != nil) {
[self saveWithManagedObjectContext: managedObjectContext.parentContext successHandler:successHandler failureHandler:failureHandler];
} else {
successHandler();
}
}
};
BOOL isMainContext = managedObjectContext.parentContext == nil;
if (isMainContext) {
[managedObjectContext performBlockAndWait:saveBlock];
} else {
[managedObjectContext performBlock:saveBlock];
}
}
It can be called from a background thread which will call save: on the NSManagedObjectContext via a performBlock: and then rescursively call this method on the parent NSManagedObjectContext in order to save it. When the app crashes, it's always on the main thread which makes sense because the main queue context is the only one that needs a persistent store.
Many thanks for any help. I did cross post to devforums.apple.com, so my apologies if you've seen this twice.
There are basically two places to look.
First, check what happens when you first add the persistent store to the Core Data stack. That would be in the app delegate if you are using the Apple template, but typically somewhere in your code when the app is initialized there is a call to
addPersistentStoreWithType:configuration:URL:options:error:.
Second, as you mention background threads and because you are passing a managed object context to your method, you possibly have child contexts. Check that you have properly assigned either a valid parent context or the store coordinator to the child context when you create it.
This error is unfortunately ambiguous. I have seen it when using configurations and there is a typo in the configuration name or in one case where a configuration name was passed in when there were no configurations in the model.
So my first line of testing would be to look at your Core Data stack creation code. Can you add that to your question so we can take a look at it?
I corresponded offline with Tom Harrington who made the innocuous comment: "Persistent stores shouldn't go away unless you remove them (and I'm assuming you don't do that)." 'course i DO do that when i tear down the core data stack (when a user logs out.) When i tear down the stack, i call reset on my root managed object context (the only one i have a reference to) and then remove the persistent store. However, if there are pending changes in a child context, they'll propagate up to my now persistentstoreless root context causing the crash on save. Since there's a good reason why parent contexts don't keep track of their children, i don't want to keep track of them either. Instead i just confirm that there is either a parent context or a persistent store coordinator (with at least one store) before calling save.
That what is happening when I delete NSManagedObjects from the data base.
GoogleAnalytics 2.0b4 void GAIUncaughtExceptionHandler(NSException *) (GAIUncaughtExceptionHandler.m:41): Uncaught exception: CoreData could not fulfill a fault for '0xe0dd380 '
libc++abi.dylib: handler threw exception
This is the latest Google Analytics SDK.
Any idea?