Cryptic error from Core Data: NSInvalidArgumentException, reason: referenceData64 only defined for abstract class

I'm doing an iPhone app that reads data from XML file, turn them into Core Data Managed Objects and save them.

The application is working fine, mostly, on smaller data set/XML that contains ~150 objects. I said mostly because 10% of the time, I'd get the following exception from CoreData while trying to save the context:

* Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '* -_referenceDat开发者_开发问答a64 only defined for abstract class. Define -[NSTemporaryObjectID_default _referenceData64]!'

On a bigger data set (~2000), this happens every time, but not on the same place. It could fail on the 137th record, 580th, or the very last one. I've tried moving the save point (per object, per 10 objects, save once all objects are alloc/init'ed) but I always hit the exception above.

I've googled the exception and saw someone having the same issues but didn't see any resolutions.

My next step was going to be simplifying the managed objects and relationships to a point where this error stops and build from there to isolate the issue. The last resort is to ditch Core Data and just directly store into sqllite.

Thanks for all your help!

---

I have the same issue. It works for smaller data sets, but for larger sets I get "_referenceData64 only defined for abstract class" errors. There's no abstract entities in my model.

EDIT:

I think I got this resolved. The issue in my case was a confusion on my part re threads. Here's the guidelines I followed to fix it:

1. I parse XML data in a thread. On launching said thread, create a new NSManagedObjectContext using the same persistent store coordinator as your main thread's NSManagedObjectContext.
2. Any new objects you make in your thread should be made for the thread's NSManagedObjectContext. If you have to copy over objects from the main thread's NSManagedObjectContext, copy over by ID. I.e.
   NSManagedObjectID *objectID = [foo objectID];
FooClass *newFoo = [(FooClass*)[threadManagedObjectContext objectWithID:objectID] retain]
3. When finished parsing, you need to save the changes made to the thread's NSManagedObjectContext. You must lock the persistent store coordinator. I used the following (incomplete code):

`

 - (void)onFinishParsing {  
  // lock the store we share with main thread's context  
  [persistentStoreCoordinator lock];  

  // save any changes, observe it so we can trigger merge with the actual context  
  @try {  
    [threadManagedObjectContext processPendingChanges];  
  }  
  @catch (NSException * e) {  
    DLog(@"%@", [e description]);  
    [persistentStoreCoordinator unlock];  
  }  
  @finally {  
    // pass  
  }  

  NSNotificationCenter *dnc = [NSNotificationCenter defaultCenter];  
  [dnc addObserver:self selector:@selector(threadControllerContextDidSave:) name:NSManagedObjectContextDidSaveNotification object:threadManagedObjectContext];  
  @try {  
    NSError *error;  
    if (![threadManagedObjectContext save:&error]) {  
      DLog(@"%@", [error localizedDescription]);  
      [persistentStoreCoordinator unlock];  
      [self performSelectorOnMainThread:@selector(handleSaveError:) withObject:nil waitUntilDone:NO];  
    }  
  } @catch (NSException *e) {  
    DLog(@"%@", [e description]);  
    [persistentStoreCoordinator unlock];  
  } @finally {  
    // pass  
  }  
  [dnc removeObserver:self name:NSManagedObjectContextDidSaveNotification object:threadManagedObjectContext];  

  [self performSelectorOnMainThread:@selector(parserFinished:) withObject:nil waitUntilDone:NO];  
}  

// Merging changes causes the fetched results controller to update its results  
- (void)threadControllerContextDidSave:(NSNotification*)saveNotification {  
  // need to unlock before we let main thread merge  
  [persistentStoreCoordinator unlock];  
  [self performSelectorOnMainThread:@selector(mergeToMainContext:) withObject:saveNotification waitUntilDone:YES];  
}  

- (void)mergeToMainContext:(NSNotification*)saveNotification {  
  NSError *error;  
  [managedObjectContext mergeChangesFromContextDidSaveNotification:saveNotification];  
  if (![managedObjectContext save:&error]) {  
    DLog(@"%@", [error localizedDescription]);  
    [self handleSaveError:nil];  
  }  
}  

`

---

You have to follow the rule:

NSManagedObjectContext must be created on the same thread which uses it. (OR in other words, every Thread must have its own MOC)

Violation of above rule cause the following exception:

• Exception in *** -_referenceData64 only defined for abstract class. Define -[NSTemporaryObjectID_default _referenceData64]!,

Another problem somebody might face is, if using the NSFetchedResultsController, the delegates will not be called on the UI classes.

I hope this answer will help someone!

---

Short Answer: you must use the following functions while saving context to ensure block operations are executed on the queue specified for the context.

perform(_:)
performAndWait(_:) 

as Mentioned in the Apple Documentation of NSManagedObject Concurrency section here

Long Answer: As Mentioned in Apple Documentation

Core Data uses thread (or serialized queue) confinement to protect managed objects and managed object contexts (see Core Data Programming Guide). A consequence of this is that a context assumes the default owner is the thread or queue that allocated it—this is determined by the thread that calls its init method. You should not, therefore, initialize a context on one thread then pass it to a different thread. Instead, you should pass a reference to a persistent store coordinator and have the receiving thread/queue create a new context derived from that.

From this we can assume

• Thread which create NSManagedObject will own that object
• you can not create NSManagedObject in one thread and save it in an other object(cause of error)
• either create Separate NSManagedObject for each thread or pass it by id as answered by Adriaan.

This will arise a new question in you mind

Is there a way to figure out what thread an NSManagedObjectContext is on?

which is already answered here and Tom Harrington answer will prove every thing above a little bit inaccurate(I also believe that) and redirect us back to the short answer:)

---

Do your mapping of nsmanagedobject data and saving of managedobjectcontext in the following block so it locks the managedobjectcontext from accessing by another thread and resolved the crash.

[context performBlockAndWait:^{

    //your code
    [context save:&error];

}];

---

sorry for my english (i'm french). I did have the same issue and I realized that I called a method on Core Data Framework (inserting an object) from a second thread. I just call this method from the Main Thread using performSelectorOnMainThread and it resolve my problem. I hope it will help you.

---

Thanks everyone, I was able to get rid of the pesky exception by following your tips.

It was the threading issue that seemed to cause the exception. In my case, I had the main thread spawning worker threads that fetch the XML, parse, create the necessary managed object, and save them.

I tried a lazy way out by using performSelectorOnMainThread for saving but that didn't work.

My final approach was to create a class called ThreadDataService with it's own ManagedObjectContext and each thread has one instance of ThreadDataService, basically what Adriaan had suggested.

Again, thanks for all the answers. You guys rock!

---

I had the same issue and when searching for an answer I found this. My problem was that I started 2 threads which worked on the same managed context is crashed when saving to the persistent store- if each thread has it own context the issue do not arise. But it might has been resolved by just locking the persistent store, but I believe the 2 managed contexts is the right solution.

Regards