views:

157

answers:

4

Hi all,

I've run into a problem with an iPhone core data application that I'm working on. I have a table that lists objects. If I select one of those objects, I go to a new ViewController that shows the detail for the object.

In the detail view, I have a back button that takes me back to the main list view.

I can select any number of rows and it will show me the detailed view for each. However, if I attempt to select a row that I've already selected, it crashes with

Program received signal: “EXC_BAD_ACCESS”.

I've added some breakpoints and tried to track this down, and found the following in my tableView cellForRowAtIndexPath method...

The first time through for each object when I do a MyEntity *thingamy = [fetchedResultsController objectAtIndexPath:indexPath] thingamy is valid and set to a valid thingamy. In gdb, I can set a breakpoint at this point and do a

po thingamy and I get the expected output.

However, the second time I select a specific row (e.g. select row 0, go back, select row 0 again), thingamy is not setup correctly.

I can view any number of other rows, but as soon as I attempt to select a row I have already viewed the detail for this occurs.

If I have the breakpoint in place and I try to do a po thingamy after it is set, I get the following:

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000020 0x92ca3ed7 in objc_msgSend ()

Any idea why fetchedResultsController returns a valid object the first call, but not the second?

UPDATE

After a few days now, I'm positive that it is not an issue with the fetchedResultsController being dealloc'd. I've enabled NSZombieEnabled mode, and there is nothing there.

Additionally, I can get other objects from the fetchedREsultsController, just not the one I have already accessed.

For example, I can get [fetchedResultsController objectAtIndexPath:[NSIndexPath indexPathForRow:0 inSection:0] and display that in my next view.

When I hit back and get back to my parent view, I can then get the object at indexPathForRow:0 inSection:1 and display that.

Coming back to the beginning again, I try to get indexPathForRow:0 inSection:0 and it crashes with EXC_BAD_ACCESS.

In a table with 100 rows, I can get every single row once, but any attempt to get the same row twice crashes, even if those attempts are one after another.

A: 

Sounds like when you go back the list has actually been destroyed and the pointers no longer reference valid memory addresses. Do you have something that disposes of the list?

Chris Lively
I don't have anything that disposes of the list - it's not really a list, it's an instance of NSFetchedResultsController.It's still valid, as I can get any other row, just not one I've already selected.
Anonymouslemming
A: 

Do you have the following method implemented?

- (void)controllerDidChangeContent:(NSFetchedResultsController *)controller {
    // In the simplest, most efficient, case, reload the table view.
    //[self.tableView reloadData];
}

Perhaps throw a breakpoint in there and see if the content is changing? Given the NSFetchResultsController talk, I figured you may be in a scenario where this could help.

sw
YepI do have that included, but looking at a breakpoint, it never gets called.
Anonymouslemming
+1  A: 

I had this exact problem with an NSFetchedResultsController. I solved it by turning on NSZombieEnabled in Xcode. In my case it turned out I was over-releasing the NSFetchedResultsController.

It worked the first time I loaded the data, but then I was releasing it without realizing it. The next time in, I released the same instance I had already released and it would crash.

If you continue to have problems, post your NSFetchedResultsController initialization code.

Matt Long
A: 

I finally found the answer to this!

In my dealloc section, I was deallocing a number of variables instead of releasing them. Now that I've changed these to release, everything is working as expected.

Anonymouslemming