CODEWITHSUNDEEP
ioscore-datansmanagedobject
dandan78
dandan78

Reputation: 13854

Corruption of NSManagedObject-derived objects when property is accessed

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.

Upvotes: 2

Views: 294

Answers (2)

Kelly
Kelly

Reputation: 1156

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;
}

Upvotes: 3

Dave Wood
Dave Wood

Reputation: 13313

It looks like your MyObject is being dealloced. I would guess you're using ARC in this case, and that you don't have anything holding on to the MyObject object (check that the NSSets the object is in are also being held somehow). Which means it will be released at the end of the current run loop and you'll see the error you're getting.

You could run Zombies in Instruments to prove this theory.

Upvotes: 0

Related Questions