I have a CoreData app I've been working on for months, and I'm
encountering a problem that appears to be caused by CoreData caching
behavior I can't control. The user-level actions that trigger the
problem are:
- I open a document (a subclass of NSPersistentDocument), and the
application automatically performs some processing that modifies the
document/datastore;
- I close the document without saving;
- I re-open the same document, and the application crashes during the
same automatic processing.
As I look into it, it seems obvious that the NSManagedContext for the
first instance of the open document is being re-used when the file is
re-opened, and I'm suspecting that the re-used context is somehow
damaged (perhaps partially released?).
The evidence:
When I close-without-saving the document for the first time, a call to
NSLog after NSPersistentDocument.close is called indicates that the
closed document's NSManagedObjectContext (actually, a
NSKVONotifying_NSManagedObjectContext) is still in memory, with a
retainCount of 2:
When I re--open the document, the automatic modification includes two
operations that use a single NSManagedObject's managedObjectContext to
find another record; what's odd is that the object's
managedObjectContext changes between the two operations, and on the
second operation, the record's managedObjectContext has the "old"
address (that of the closed document) and a className that lacks the
NSKVONotifying_ prefix.
Note the change in class name. A call to executeFetchRequest using
this context fails.
A couple of notes:
- I now construct a new NSFetchRequest for executeFetchRequest, so
this isn't a fetched property issue.
- I have used ObjectAlloc to debug this, and it confirms that the
first document's managedObjectContext remains allocated after its
"host" document has been released.
I'm stumped. Any suggestions?
As always, TIA and thanks for the great help I've received here in the past.
