CODEWITHSUNDEEP
ioscore-datacrashnsfetchedresultscontroller
Andrea Sprega
Andrea Sprega

Reputation: 2271

NSFetchedResultsController randomly crashes with NSInvalidArgumentException

I have an iOS application which uses Core Data to temporarily store some data downloaded by internet into a database. These data are used to populate an UITableView through a NSFetchedResultsController. Here's the code (placed into the UIViewController) which generates the controller:

- (NSFetchedResultsController *)fetchedResultsController {

if (fetchedResultsController != nil) {
    return fetchedResultsController;
}

// Fetch results from database
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription entityForName:@"Order" inManagedObjectContext:[self.appDelegate ordersObjectContext]];
[fetchRequest setEntity:entity];

NSSortDescriptor *sort = [[NSSortDescriptor alloc] initWithKey:@"patronName" ascending:YES];
[fetchRequest setSortDescriptors:[NSArray arrayWithObject:sort]];

// Prefetch size: tweak this to improve performance
[fetchRequest setFetchBatchSize:20];

NSFetchedResultsController *theFetchedResultsController = [[NSFetchedResultsController alloc] initWithFetchRequest:fetchRequest managedObjectContext:[self.appDelegate ordersObjectContext] sectionNameKeyPath:@"patronNameInitial" cacheName:nil];
self.fetchedResultsController = theFetchedResultsController;
fetchedResultsController.delegate = self;

[entity release];
[sort release];
[fetchRequest release];
[theFetchedResultsController release];

return fetchedResultsController;

}

In my application work flow, the table view to which this controller is wrapped has to be unloaded and loaded several time, and here comes the problem. Once the context is populated by my "Order" entities, if I switch back and forth to the view with the results controller, after several times of pushes and pops from the view stack the application crashes with the following error:

Fatal error. NSInvalidArgumentException. Entity name must not be nil.. User info: (null)

The curious thing is that, for a given set of data that the controller has to display, the crash occurs EXACTLY at the same time in every application run. Example: always at the sixth time I display the view with the data.

But how is this possible if my object context does not change in the meanwhile? Why (example) it works 5 times the sixth time I get this error?

Please note that my managed object context and model are owned by my application delegate and never unloads, so the data should not change over time if I don't explicitly modify them.

Maybe the issue is because I don't actually save the "Orders" to the database but I keep them in memory, in the object context? I do this because when the application stops, the downloaded data has to be wiped.

EDIT 1: I tried to log right the line before the crash occurs, and 

NSLog(@"%@", [[self.appDelegate managedObjectModel] entities]);

Is causing the application to crash with EXC_BAD_ACCESS, so the problem occurs in the managedObjectModel.

EDIT 2: I tried to fill the context with more than 1500 entities, and I after loading and unloading the view for 30 times I didn't have any crash. It seems I get crashes only when the managed object context contains only few entities! This is so weird.

Upvotes: 0

Views: 329

Answers (2)

Sherman Lo
Sherman Lo

Reputation: 2759

You shouldn't be releasing entity

[entity release];

Since you never called alloc on it, you don't own it.

Upvotes: 3

d.ennis
d.ennis

Reputation: 3455

I noticed that you are not caching section informations. Why not ? Set cacheName:@"Root" to use the advantage of the NSFetchResultController. Note that this only makes sense if the settings of the FetchRequestController are immutable. As far as I can see in your posted code, that's what you have here. So you should go ahead and cache your section informations. Your data will only be loaded into the cache on first launch with a little bit of overhead but later on only observes changes in your table view.

I am trying to think if that could also be a reason for your problem but only have vague assumptions I am not sure about, so I will leave them out here. But try changing that...

Upvotes: 0

Related Questions