-[_NSDefaultSectionInfo indexOfObject:] throws "Invalid range" exception

Originator:kemenaran
Number:rdar://13096498 Date Originated:28-Jan-2013 04:24 PM
Status:Open Resolved:
Product:iPhone SDK Product Version:6.1 (10B141)
Classification:Crash/Hang/Data loss Reproducible:Always
 
SUMMARY:

A exception occurs in the internal methods of NSFetchedResultsController when processing a set of changes where a managed object is deleted from a MOC.

During _postprocessDeletedObjects:, -[_NSDefaultSectionInfo indexOfObject:] is called ; the first argument is a managed object that has been deleted. This triggers an exception:

    CoreData: error: Serious application error.  Exception was caught during Core Data change processing.  This is usually a bug within an observer of NSManagedObjectContextObjectsDidChangeNotification.
    *** -[NSArray indexOfObject:inRange:]: range {0, 2} extends beyond bounds [0 .. 0] with userInfo (null)

The NSFetchedResultsController has no explicit sections (sectionNameKeyPath = nil). There where two fetched objects before the deletion, and one after.

Comments

it has already the new data, applying these updates will fail at some point. DS1302

By joey899244 at Feb. 2, 2013, 9:16 a.m. (reply...)

I got a more precise description of the issue.

DESCRIPTION:

This crash occurs when a UITableView is initialized during an NSFetchedResultsController content update sequence (if some objects are removed during the update sequence).

More precisely, the issue lies in the standard boilerplate code for wiring an NSFetchedResultsController to an UITableViewController:

  • (void)controllerWillChangeContent:(NSFetchedResultsController *)controller { // The following line can cause the tableView to load and to reload its data [self.tableView beginUpdates]; }

If the view controller's view is not loaded at this point, it will be loaded during the controllerWillChangeContent: execution. The table view will also load its data from the datasource - which will query the FRC, which will return the new data.

Then the tableView will try to apply the updates from the FRC, but as it has already the new data, applying these updates will fail at some point.

ISSUE:

If the FRC has a sectionNameKeyPath, the crash will be pretty explicit: during -endUpdate, the tableView will throw an NSInternalConsistencyException with a detailed error message. This helps to spot the issue with the lazy-loading.

However, if the FRC has no sectionNameKeyPath, it will throw a array-out-of-bounds exception in -[_NSDefaultSectionInfo indexOfObject:]. This makes it considerably more difficult to debug, and to discover the issue with the lazy loading.

EXPECTED RESULTS:

Even in the "no sectionNameKeyPath" scenario, the FRC should throw an explicit exception — rather than an out-of-bounds access to an internal array.

By kemenaran at Feb. 1, 2013, 10:04 a.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!