FRC throws an exception when used on entities with transient property: 'statement is still active'
| Originator: | constantine | ||
| Number: | rdar://20552693 | Date Originated: | 15-Apr-2015 |
| Status: | Closed | Resolved: | iOS 9 Beta 5 (build 13A4325c) |
| Product: | iOS | Product Version: | 8.x |
| Classification: | Exception | Reproducible: | YES |
Summary: We use NSFetchedResultsController to display entities with a transient property. This transient property used by FRC to separate objects into different sections. If FRC performs fetch and any context with `NSPrivateQueueConcurrencyType` executes fetch request on a private queue application crashes with the following exceptions: *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'statement is still active' or *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '_obtainOpenChannel -- NSSQLCore 0x1464ecf0: no database channel is available' Steps to Reproduce: 1. Download sample project and run it an device or simulator. 2. Soon after launching the application you should get the exception. Expected Results: I would expect 1 million dollars and job offer from Apple, but we can start with something easer: FRC should be thread safe. Actual Results: I have no many, no job offer, but only exception together with frustrated users :) https://www.dropbox.com/s/h8xtlk7ggc02eus/CoreData.zip?dl=0
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!
Hi. You can work around this problem if you give the NSFetchedResultsController's NSManagedObjectContext its own NSPersistentStoreCoordinator (connected to the same persistent store, of course).
The other workaround, which I do not recommend, is to wrap every other NSManagedObjectContext's performBlock or performBlockAndWait calls inside the NSPersistentStoreCoordinator's performBlock or performBlockAndWait
I'd love the million dollars too, btw.