CODEWITHSUNDEEP
iphoneios
Steve Potter
Steve Potter

Reputation: 1919

UITableView occasional crash while appending rows

My app has a UITableViewController that is getting an "Invalid Update: invalid number of rows in section 0..." after appending rows. Thing is, it happens only in %0.2 of sessions. Our app, has millions of sessions so the crashes are adding up.

The flow is simple. It's part of a feature that matches a user's music with our catalog of videos. A background thread makes a series of requests. A request goes out, response comes back with results, then those results get appended to a tableView within one of our tabs. The requests go in batches and can add up to lots of resulting rows. So rather than call reloadData after a batch comes in, I wanted to append them properly. Works awesome, but occasionally crashes.

I was able to reproduce this one time on a device. It has never happened on simulator. As far as I know, the crash is reasonably random, although it mostly happens on 3gs. The fewest # of crashes come from 4s.

Here's the code. A response comes back. In this case, allMatches is every match so far (the data source for the table). batchMatches is the number of new artists. Both are arrays:

    [self.tableView beginUpdates];
    NSMutableArray *paths = [[NSMutableArray alloc] init];
    for (int i = [allMatches count] - [batchMatches count]; i < [allMatches count]; ++i) {
        NSIndexPath *indexPath = [NSIndexPath indexPathForRow:i inSection:0];        
        [paths addObject: indexPath];
    }
    [self.tableView insertRowsAtIndexPaths:paths withRowAnimation:NO]; 
    [self.tableView endUpdates];
    [paths release];

Code is pretty simple. It just appends rows to the end, one for each result. Never deletes. An example of full exception message is "Invalid update: invalid number of rows in section 0. The number of rows contained in an existing section after the update (131) must be equal to the number of rows contained in that section before the update (131), plus or minus the number of rows inserted or deleted from that section (20 inserted, 0 deleted) and plus or minus the number of rows moved into or out of that section (0 moved in, 0 moved out)." Numbers are all over the place in actual crash reports, so it's not a specific batch number.

Like I said, it almost always works. And it crashes usually on 3GS. I'm wondering if this could possibly be a framework bug. I could always call reloadData after each batch returns but it results in ugly flashing of table cells each time. On purpose I triggered the exception and it seems after that the table is dead, so I couldn't do a try/catch with a reloadData as a fallback in the catch block.

Can anyone out there shed some light? Apologies for length of this post.

EDIT: The server requests are done using NSOperationQueue, so they are on a background thread. When the response returns, I post a notification on the main thread, which causes the table code to run. The notification is posted like this:

NSNotification *notification = [NSNotification notificationWithName:notificationName object:self];
[self performSelectorOnMainThread:@selector(postNotification:) withObject:notification waitUntilDone:NO];

Post notificiation is simply a wrapper around [[NSNotificationCenter defaultCenter] postNotification:notification]. So the table code should be on the main thread.

Upvotes: 1

Views: 228

Answers (1)

Felix
Felix

Reputation: 35394

My guess is, you are executing the table view update in a background thread. You should do that on the main thread instead.

Place your code inside a dispatch_async block.

dispatch_async(dispatch_get_main_queue(), ^(void) {
       // ..
});

Upvotes: 1

Related Questions