Question

I have a class that at some point gets a bunch of data with a Core Data fetch and then inserts the objects, created in the usual Core Data way in XCode and therefore derived from NSManagedObject, into an NSMutableSet. Depending on how things work out, some of these objects might end up in several other sets. So far, so good.

But then the following happens:

NSMutableArray* anArray = [NSMutableArray alloc] init;
[currentResults minus:previousResults]; // both are NSMutableSets
for(MyObject* obj in currentResults)
{
   [anArray addObject:[createAnnoFromMyObject:obj]]; // nastiness happens here
}

All createAnnoFromMyObj: does is pull data out of obj and return a object that implements MKAnnotation.

The problem is that although I get an array of usable annotations, currentResults, previousResults, and any other objects that references any of the MyObjects that were touched by createAnnoFromMyObject: end up getting trashed.

By trashed I mean that trying to access them results in an exception along the lines of

-[MyObject beginningOfDocument]: unrecognized selector sent to instance...

The same happens when trying to view any of these collections in the debugger pane with the po command.

We tried regenerating MyObject in Core Data but no luck. There is very little mention of this beginningOfDocument selector on Google and we have no idea what coudl be wrong. Although we have a workaround that will probably eliminate this issue, it would be really nice to know what is going on.

Answer 1

I also ran into this specific unrecognized selector problem – that beginningOfDocument was being called on my (subclass of) NSManagedObject instance in iOS5.x. The problem looks to be fixed in iOS6 though. I also verified that NSZombies gave me nothing, even though it certainly seemed like the right intuition.

The unrecognized selector exception was thrown during a valueForKey lookup on our managed object, so it’s worth looking at the stack trace to see if this is where the exception is thrown for you as well.

In our case, the “broken” key was fullText, the name of one of our attributes. Changing the name eliminated the problem. My guess is that the name caused an error in the underlying sqlite query (I didn’t think fulltext was a keyword, but maybe for the full text searching in sqlite?), and perhaps the query arguments are better sanitized in iOS6.

You can find out what key/attribute name is broken with this little cheat: Override your valueForKey: method temporarily to NSLog and then just call the superclass version and return it. Even though the docs say not to override it (which we’re only doing for a moment to find the offending attribute), this is ok since we’re just overriding and then calling the superclass implementation.

// Don't forget to remove me after the bug is fixed!
- (id)valueForKey:(NSString *)key {
    NSLog(@"Finding value for key: %@", key);
    return [super valueForKey:key];
}

Then when you run again, you’ll see the last call to valueForKey: before the crash and know what attribute name is broken.

If you’re still having trouble sorting out which was the unsuccessful lookup, you could go with the more verbose:

// Don't forget to remove me after the bug is fixed!
- (id)valueForKey:(NSString *)key {
    NSLog(@"Finding value for key: %@", key);
    id retVal = [super valueForKey:key];
    NSLog(@"Success for key: %@", key); // or print retVal for fun
    return retVal;
}