How to debug/handle intermittent "authorization denied" and "disk i/o" errors when adding SQL store to an NSPersistentStoreCoordinator?

I have an app in the app store and am using a logging service to get crash logs and associated log data. I am seeing an intermittent crash (low # of users affected and low # of crashes per user) but it is baffling me.

What happens in these crashes is the following:

App launches and initializes Core Data stack

App attempts to add a SQL store to the NSPersistentStoreCoordinator with the following code (storeURL is valid):

NSDictionary *options = @{
    NSMigratePersistentStoresAutomaticallyOption : @(YES),
    NSInferMappingModelAutomaticallyOption : @(YES)
};

sqlStore = [_persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
                                                     configuration:nil
                                                               URL:storeURL
                                                           options:options
                                                         error:&error];

One of the following errors occur when adding this store:

NSError:

Domain=NSCocoaErrorDomain
Code=256 "The operation couldn’t be completed. (Cocoa error 256.)"
UserInfo=0x1dd946a0 {NSUnderlyingException=authorization denied, NSSQLiteErrorDomain=23}

NSError:

Domain=NSCocoaErrorDomain
Code=256 "The operation couldn’t be completed. (Cocoa error 256.)"
UserInfo=0xc6525d0 {NSUnderlyingException=disk I/O error, NSSQLiteErrorDomain=10}

After this condition, the app will crash b/c the SQL store is required for the app to function. I could attempt to gracefully handle this failure by trying a new storeURL but I don't want the user to lose existing data. Also, I have never personally reproduced this issue and based on the low number of users affected and crash logs I believe it is a low impact problem and does not recur on a subsequent app launch.

I'm hoping there's a Core Data guru out there with some suggestions on how to debug and prevent/handle these conditions. My core data stack initialization code is straight from the xcode project generator and I have ruled out any concurrency issues in that the persistent store coordinator is only initialized once (on launch) and this error occurs in this initialization.

Happy to provide more code/info if relevant.

thanks!

Solution

It looks like XJones and I have been able to locate the cause of this. It appears to be an iOS edge-case bug or undocumented behavior. I've filed this under Apple bug ID 12935031.

There is an unaccounted for scenario where an application using Core Location significant location change or region monitoring can fail to launch properly (or have other unintended consequences) due to the fact that as of iOS 5, Core Data stores use data protection (encryption) by default.

Steps to Reproduce:

1) Turn on pass code protection on the device

2) Create an application that starts Significant Location Monitoring or Region Monitoring and keeps it started even when in the background. Ie. An app that uses background significant location change or region monitoring.

3) Wait for the battery on the device to run out (there may be other causes as well)

4) The device will shut down

5) Connect the device to the Mac

6) Once the charge is adequate, the device will boot. Important: Do not unlock device at this time.

7) Exit or enter the monitored range or cause a significant change in location to occur. The device will now automatically relaunch the application, because it registered for Significant Location Monitoring or Region Monitoring

8) However, since the device has not been unlocked by the user (pass code not yet entered), the application will not be able to read any of its protected data files. In a Core Data application, this will cause the persistent store coordinator to fail to add the persistent store file to the managed object context. This will cause the app to crash or depending on the code used by the developer even attempt to reset the database. In other apps it may cause crashes for other reasons as this is an unexpected, undocumented side effect of the data protection feature being turned on by default for Core Data stores in iOS 5 and later.

The solution or workaround until Apple corrects this or at least documents it is to either make sure your application stops monitoring significant location changes/regions in applicationWillTerminate or to turn off the default data protection feature by setting NSFileProtectionNone for the NSFileProtectionKey key in the options dictionary when adding the Core Data store to the persistent store coordinator. to wait for the file store to become available using a while() loop that checks for the protected data to become available. There may be other ways of doing this using KVO, but this method works reliably and is easiest to insert into existing code without reworking your entire application startup process.

~~Update: looks like just setting that key is not enough if data protection is already active on the store. You have to manually set it:~~



[[NSFileManager defaultManager] setAttributes:[NSDictionary dictionaryWithObject:NSFileProtectionNone forKey:NSFileProtectionKey] ofItemAtPath:storePath error:nil];

Here's the fix for apps that need background location monitoring, thanks to more input from XJones and a bit more research in Apple's scattered docs:



while(![[UIApplication sharedApplication] isProtectedDataAvailable]) {
    [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:0.5f]];
}

This code goes in before you attempt to add the store data file to the persistent store coordinator.

Update 2015: You can also set NSPersistentStoreFileProtectionKey to NSFileProtectionNone. This will properly disable file protection (if you don't need it) and just work without requiring any workarounds. The reason it did not work in previous attempts is because the dictionary key I was testing with was incorrect.