NSFetchedResultsSectionInfo disagrees with itself about how many objects it has

I posted this on the Apple dev forums here since it feels to me like a bug in the actual SDK, but I thought I'd post it here as well 开发者_JAVA技巧and see if anyone could verify whether or not I'm using this thing incorrectly (doesn't seem like it) or this is broken behaviour.

https://devforums.apple.com/thread/72738

--

After spending a little while debugging some code, I have discovered a very strange and worrying behaviour of an instance of NSFetchedResultsSectionInfo.

NSFetchedResultsController *frc = [self frcForTableView:tableView];

id <NSFetchedResultsSectionInfo> sectionInfo = [[frc sections] objectAtIndex:
                                                [indexPath indexAtPosition:1]];

NSLog( @"Looking at %@ with section %@ (%d objects)",
       indexPath, [sectionInfo objects], [sectionInfo numberOfObjects] );

Basically, I grab a FRC, then pull one of the sectionInfo objects out of it (don't worry about why I'm grabbing for index path position 1 rather than 0 ... it shouldn't matter here). The interesting thing is that the NSLog output for the above is this:

Looking at <NSIndexPath 0x8828ee0> 2 indexes [0, 0] with section (
    "TBN.B x 1 for order 1187",
    "TBN.T x 1 for order 1187"
) (1 objects)`

So the [sectionInfo objects] array has two things in it, but [sectionInfo numberOfObjects] reports that it only has one. To eliminate the possibility of a caching issue I disabled all caching in the FRC setup prior to running this code.

Pretty stumped here. Don't know how a single sectionInfo object can disagree with itself about how many objects it has in it.

Any ideas from the Apple devs? Running XCode 3.2.4 and the 4.1 SDK.

Edit: FYI the correct object for this section is actually the first one (TBN.B) so in my testing so far it appears that if you only consider the portion of the objects array up to numberOfObjects then you get the right results. Nevertheless, still curious as to why the extra object appears at the end of the array when it isn't part of that section.

Here it is 5 1/2 years after the question was originally asked. We're on Xcode 7.x and the bug seems to still be here. Has anyone figured out why this is happening. The solution I've come up with is simply to check for this condition in controllerDiDChangeContent and if it exists, recreate the FRC. For me, it's ok since this only happens when you start with 0 sections and add a 2nd one beneath it. Here's a very good writeup on how to recreate this bug. I guess not that many people are putting totals in their footers.

https://devforums.apple.com/message/328077#328077

My tests have shown that the "objects" array of the first section always contains all the objects in the controller. I think thats a framework bug.

Thats a really dirty (and slow) workaround:

NSArray * allObjects = self.cachedFetchedResultsController.fetchedObjects;
NSMutableArray * objectsInSectionZero = [NSMutableArray array];
for (id obj in allObjects) {
    if ([[self.cachedFetchedResultsController indexPathForObject:obj] section] == indexPath.section) {
        [objectsInSectionZero addObject:obj];
    }
}