CODEWITHSUNDEEP
iosobjective-cuitableviewmemory-management
Adam M.
Adam M.

Reputation: 79

Memory Errors with Editable UITableView (iOS 7 ARC)

I'm having some trouble with bad memory access in my app, and it only occurs for a specific scenario, which I will outline here:

1) Swipe left on a table cell and delete it using the delete button that appears in the right side of the cell (once or for multiple cells).

2) Before doing anything else (such as adding another cell to the table), press the back button on the navigation bar.

3) Current view controllers pops off the navigation stack.

4) Previous view controller loads and view appears.

5) The view controller previously popped off the stack gets its dealloc message.

6) Memory access issue appears to occur at this point.

I could use some help identifying the source of the trouble. Here's what the thread looks like at the point the app crashes:

Thread

Here's the error message:

Thread 1: EXC_BAD_ACCESS (code=1, address=0xe16d7b52)

The address it gives differs from time to time, but beyond that it's always the same message. I do know that it happens after step 5 above, because I placed a breakpoint in that view controller's dealloc method:

- (void)dealloc
{
    // BUGFIX: prevent the tableview from calling delegate methods after
    //   this point.
    photosTableView = nil;    // Problem is at some point after this.

    // [super dealloc]; // Not necessary to explicity call this in ARC
}

You'll see I tried setting the table to nil right off, that didn't change anything, still crashes in the same fashion as before. Note that this only happens for the scenario I outlined above. Pressing back if you haven't deleted a cell from the table doesn't crash the app, nor does moving forward directly after you have deleted a cell, doing anything in between deleting the cell and pressing the back button will cause the app not to crash. Any advice on how to track down the cause of this issue would be appreciated.

EDIT: I think my problem might be how I've implemented this method:

- (void)tableView:(UITableView *)tableView
commitEditingStyle:(UITableViewCellEditingStyle)editingStyle
forRowAtIndexPath:(NSIndexPath *)indexPath {
    // If the tableView is asking to commit a delete command...
    if (editingStyle == UITableViewCellEditingStyleDelete) {
        // Remove the image from the store
        [[SFMImageStore sharedCache] deleteImageAtIndex:[indexPath row]];

        // Reload the table
        [tableView reloadData];
    }
    // EDIT: Adding this forces the tableView out of editing mode
    [tableView setEditing:NO];
}

I tried commenting out [tableView reloadData] just to see what happens, and predictably, the cell is still present in the table (because it hasn't been reloaded). What surprised me though, was that the delete button was also still there. That is what led me to believe that perhaps what I'm doing here might be to blame.

EDIT: Forcing the table to exit editing mode stops the message from printing (I should have done that to begin with anyway), but it's still strange that the tableView would get a reloadData message when dealloc is called.

Upvotes: 1

Views: 497

Answers (2)

kbokdia
kbokdia

Reputation: 459

While pressing the back button in navigation bar set tableview.editing to NO

//Back Button clicked
- (void)backButtonClicked{
   [tableView setEditing:NO];
}

Hope this works for you.

Upvotes: 1

Mike1in3
Mike1in3

Reputation: 481

I've had this problem as well in rare circumstances. On doing an unwind segue, occasionally the source view controller will be deallocated by ARC before the destination view presents itself. It doesn't happen on very many of my unwind segues, but on the ones that it does, it happens every time. I don't know why it happens. What I did to work around it was to set a pointer to the source VC in the destination "VC's" unwind segue IBAction method that I clear in viewWillAppear. It's not pretty, but it works.

FYI when I checked the zombies instrument, I found that the deallocation was happening prior to an internal Apple procedure call in cleaning up the source view controller. The procedure call had something to do with the searchBar (although I didn't have one on my VC).

Upvotes: 0

Related Questions