Question

My app makes updates in background thread then saves context changes.
And in main context there is a table view that works with NSFetchedResultsController.
For some time updates work correctly, but then exception is thrown.
To check this I’ve added NSLog(@"%@", [self.controller fetchedObjects]); to -controllerDidChangeContent:.
Here is what I got:

"<PRBattle: 0x6d30530> (entity: PRBattle; id: 0x6d319d0 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p2> ; data: {\n    battleId = \"-1\";\n    finishedAt = \"2012-11-06 11:37:36 +0000\";\n    opponent = \"0x6d2f730 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p1>\";\n    opponentScore = nil;\n    score = nil;\n    status = 4;\n})",
"<PRBattle: 0x6d306f0> (entity: PRBattle; id: 0x6d319f0 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p1> ; data: {\n    battleId = \"-1\";\n    finishedAt = \"2012-11-06 11:37:36 +0000\";\n    opponent = \"0x6d2ddb0 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p3>\";\n    opponentScore = nil;\n    score = nil;\n    status = 4;\n})",
"<PRBattle: 0x6d30830> (entity: PRBattle; id: 0x6d31650 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p11> ; data: <fault>)",
"<PRBattle: 0x6d306b0> (entity: PRBattle; id: 0x6d319e0 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p5> ; data: {\n    battleId = 325;\n    finishedAt = nil;\n    opponent = \"0x6d2f730 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p1>\";\n    opponentScore = 91;\n    score = 59;\n    status = 3;\n})",
"<PRBattle: 0x6d30730> (entity: PRBattle; id: 0x6d31a00 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p6> ; data: {\n    battleId = 323;\n    finishedAt = nil;\n    opponent = \"0x6d2ddb0 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p3>\";\n    opponentScore = 0;\n    score = 0;\n    status = 3;\n})",
"<PRBattle: 0x6d307b0> (entity: PRBattle; id: 0x6d31630 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p9> ; data: {\n    battleId = 370;\n    finishedAt = \"2012-11-06 14:24:14 +0000\";\n    opponent = \"0x79a8e90 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p2>\";\n    opponentScore = 180;\n    score = 180;\n    status = 4;\n})",
"<PRBattle: 0x6d307f0> (entity: PRBattle; id: 0x6d31640 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p10> ; data: {\n    battleId = 309;\n    finishedAt = \"2012-11-02 01:19:27 +0000\";\n    opponent = \"0x79a8e90 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p2>\";\n    opponentScore = 120;\n    score = 240;\n    status = 4;\n})",
"<PRBattle: 0x6d30770> (entity: PRBattle; id: 0x6d31620 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p7> ; data: {\n    battleId = 315;\n    finishedAt = \"2012-11-02 02:26:24 +0000\";\n    opponent = \"0x79a8e90 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p2>\";\n    opponentScore = 119;\n    score = 179;\n    status = 4;\n})"

)

Faulted object (0xe972610) here causes crash. I’ve logged data during update & before saving. This object is in updatedObjects only. Why can this method return “bad” object?
(Moreover, during updates this object is affected almost each update. And only after some passes becomes “bad” one).

P.S.: I use RestKit to manage CoreData.

UPDATE2:

Looks like the problem is in [self.controller fetchedObjects] enumeration. It is called from - (void)controllerDidChangeContent:(NSFetchedResultsController *)controller and seems these objects are modified even during this method call (I mean CoreData update wasn’t finished to that point). Is it possible?

UPDATED:

The exception was got, when I did smth. like this:

for (PRBattle *battle in [self.controller fetchedObjects) {
    switch (battle.statusScalar) {
        case ...
        default:
            [battle willAccessValueForKey:nil];
            NSAssert1(NO, @"Unexpected battle status found: %@", battle);
    }
}

The exception is on line with -willAccessValueForKey:. Scalar status for battle is enum, that is bind to integer values 1..4. I’ve mentioned all possible values in switch’s cases (above default:). And the last one has break;. So this one is possible only when battle.statusScalar returns non-enum value.

Status scalar implementation in PRBattle:

- (PRBattleStatuses)statusScalar
{
    [self willAccessValueForKey:@"statusScalar"];
    PRBattleStatuses result = (PRBattleStatuses)[self.status integerValue];
    [self didAccessValueForKey:@"statusScalar"];
    return result;
}

And battle.status has validation rules:
– min-value: 1
– max-value: 4
– default: no value

And the last thing – debug log:

objc[4664]: EXCEPTIONS: throwing 0x7d33f80 (object 0xe67d2a0, a _NSCoreDataException)
objc[4664]: EXCEPTIONS: searching through frame [ip=0x97b401 sp=0xbfffd9b0] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: catch(id)
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x97b401 sp=0xbfffd9b0] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: handling exception 0x7d33f60 at 0x97b79f
objc[4664]: EXCEPTIONS: rethrowing current exception
objc[4664]: EXCEPTIONS: searching through frame [ip=0x97b911 sp=0xbfffd9b0] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0x9ac8b7 sp=0xbfffdc20] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0x97ee80 sp=0xbfffdc40] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0x361d0 sp=0xbfffdc70] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0xa701d8 sp=0xbfffde10] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: catch(id)
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x97b911 sp=0xbfffd9b0] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: finishing handler
objc[4664]: EXCEPTIONS: searching through frame [ip=0x97b963 sp=0xbfffd9b0] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0x9ac8b7 sp=0xbfffdc20] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0x97ee80 sp=0xbfffdc40] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0x361d0 sp=0xbfffdc70] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0xa701d8 sp=0xbfffde10] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: catch(id)
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x97b963 sp=0xbfffd9b0] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x9ac8b7 sp=0xbfffdc20] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x97ee80 sp=0xbfffdc40] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x361d0 sp=0xbfffdc70] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x3656f sp=0xbfffdc70] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0xa701d8 sp=0xbfffde10] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: handling exception 0x7d33f60 at 0xa701f5
2012-11-07 13:37:55.463 TestApp[4664:fb03] CoreData: error: Serious application error.  An exception was caught from the delegate of NSFetchedResultsController during a call to -controllerDidChangeContent:.  CoreData could not fulfill a fault for '0x6d31650 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p10>' with userInfo {
    NSAffectedObjectsErrorKey =     (
        "<PRBattle: 0x6d30830> (entity: PRBattle; id: 0x6d31650 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p10> ; data: <fault>)"
    );
}

Answer 1

Crash main reason: “Saving in a Background Thread is Error-prone” (http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/CoreData/Articles/cdConcurrency.html//apple_ref/doc/uid/TP40003385-SW7). Of course, I’ve read this before. But the problem became bigger with RestKit. It works with “contextForCurrentThread”. So you get sole context for background thread as it should be (according to the same document). But you can’t save it from main thread, except when you pass it directly, cause in main thread this method returns another context. When I’ve seen this, I thought RestKit fixed this for me (during “normal” save, not from main thread), but no.

The second thing is NSFetchedResultsController. When you call [self.controller fetchedObjects] from -controllerDidChangeContent: you should be ready, that this array can be changed in time. I took this array and, making enumeration, retrieved necessary data. And during enumeration it was changed (I think, it’s a NSMutableArray returned wity typecast to NSArray – so this behavior becomes possible). You will never see this in “default” behavior (when you get objects with objectForIndexPath: for each rendered cell – as in Apple examples), but in my app I have additional cells, except containing data objects. So I need to generate my own storage, instead of using controller’s fetched results directly. And this way I will recommend to avoid using NSFetchedResultsController at all. I’ve replaced it with simple NSManagedObjectDidSaveNotification observer and loading data each time.