Question

The good facts:

• I download data from the server, and, via Core Data thread confinement, save the data, and when the background MOC is saved, the main MOC gets merged.
• All the saving operations go ok
• Also the merging of the MOC happens without any problems

The bug I’m hunting:

• When my UITableView with NSFetchedResultsController is active (i.e. on the screen), and the saving is happening, the app crashes with a SIGABRT that takes me to the mergeChangesFromContextDidSaveNotification line in AppDelegate.
• What is the most strange part is, that when the delegate of the FRC is nil, or when it is my view controller but i don’t implement any FRC delegate methods, the crash doesn’t happen and I don’t have any problem. But when I implement any of the delegate methods (even empty, without a single line of code), the app crashes with the same bug. It means that the methods are not even being fired, the problem is not in the code inside these methods.
• The strangest part 2 (CHECK UPDATE 2 BELOW): the crash happens with a [__NSCFNumber length]: unrecognized selector sent to instance and I don’t call any ‘length’ property in my CoreDataManager neither in my AppDelegate class

The witness: console

<CoreDataManager.m:(338)> Saved data from server
<AppDelegate.m:(352)> Will merge
<CoreDataManager.m:(338)> Saved data from server
<AppDelegate.m:(355)> Did merge
<CoreDataManager.m:(338)> Saved data from server
<AppDelegate.m:(352)> Will merge
<AppDelegate.m:(355)> Did merge
<CoreDataManager.m:(338)> Saved data from server
<CoreDataManager.m:(338)> Saved data from server
<CoreDataManager.m:(338)> Saved data from server
<MyTableViewController.m:(134)> Fetched results controller did fetch 
<CoreDataManager.m:(338)> Saved data from server
<CoreDataManager.m:(338)> Saved data from server
<CoreDataManager.m:(338)> Saved data from server
<AppDelegate.m:(352)> Will merge
<CoreDataManager.m:(338)> Saved data from server
[__NSCFNumber length]: unrecognized selector sent to instance 0x13318050

Some code – Merging the MOCs

- (void)managedObjectContextDidSave:(NSNotification *)notification
{
    NSManagedObjectContext *sender = (NSManagedObjectContext *)[notification object];

    if ((sender != self.managedObjectContext) &&
        (sender.persistentStoreCoordinator == self.managedObjectContext.persistentStoreCoordinator))
    {
        dispatch_async(dispatch_get_main_queue(), ^{
            DebugLog(@"Will merge");
            [self.managedObjectContext mergeChangesFromContextDidSaveNotification:notification];
            DebugLog(@"Did merge");
        });
    }
}

Update 1

Following Cocoanetics hint, I created a NSNumber category to check who is calling length. I got what you see below, and a crash in [__NSCFNumber _fastCStringContents:]: unrecognized selector sent to instance.

Update 2
Enabling zombies didn’t help =(

Answer 1

Well, after months and hours, I finally got a solution. It works, and I would love to hear some opinions on why.

So, as I said, the saving was working 100%, as well as the merging notifications. If I set the NSFetchedResultsController delegate to nil, there was no problem. However, setting the delegate to my UIViewController, made the app crash.

I thought it could be, maybe due to my code when the delegate methods were triggered. But the app crashed even before that. So I followed Cocoanetics tip, to create a category and try to figure out who was calling the length method to the NSNumber object. After that, I saw that the NSPredicate was calling - (BOOL)evaluateWithObject:(id)object; before getting to the crash. In the same way, I did a category to override it:

@interface NSPredicate (PractiPredicate)
- (BOOL)evaluateWithObject:(id)object;
@end

@implementation NSPredicate (PractiPredicate)

- (BOOL)evaluateWithObject:(id)object
{
    NSLog(@"Evaluate was called. Object class %@", NSStringFromClass([object class]));
    MyManagedObject *myManagedObject = object;
    NSLog(@"Is fault? %d", myManagedObject.isFault);
    NSLog(@"myManagedObject changed and already have propertyA? %d", myManagedObject.propertyA != nil);
    return YES;
}

@end

So, for my surprise, it worked, and generated te following logs:

Evaluate was called. Object class MyManagedObject

Is fault? 0

myManagedObject changed and already have propertyA? 1

I decided to print "Is fault?" because I thought that this mess was related to NSManagedObject faulting, but, for what it printed, it’s not.

Question for the comments: What do you think that could have generated this problem here?