Question

I have created a window based application with the following

• a TableViewController (Without a XIB file)
• a ViewController (With a XIB file) <– to be used as modal view
• a CoreData model to store some data

I managed to load the application and populate the TableView with the data from the Entity, and I was able to scroll through all of the cells of the TableView, without any issues.

I added a UIBarButton item (rightBarButton) that causes a Modal View to appear for the user to input some data. The model view has a SAVE and CANCEL buttons.

The problem is once I press the Cancel Button, I go back to the TableView but if I try to scroll throgh the items in the tableview, the app crashes.

After 4 hours of searching Google and StackOverflow, I was not able to see why my app crash. I did however notice by the debugger that the ManagedObjectContext is set to NIL the second time I scroll the tableview (after the modalview is dismissed), although no data is changed and no insertion/deletion occured.

I tried using a timer to call reloadData as I found some answers on StackOverflow, but that did not work. I tried setting the ManagedObjectContext as a property with retain and removed all occurences of [myManagedObjectContext release] to avoid releasing it earlier than needed, but that did not help.

It seems that I am doing an obvious mistake, but I am not sure where.

Please help.

Answer 1

ivars do not become nil just because they’re released somewhere else (at least not in iOS 4.3). So an over-release is not the specific cause of myManagedObjectContext becoming nil. Assuming you’re using accessors to reference your ivars (and you should be), hand-implement setManagedObjectContext: and put a breakpoint in there to see who’s calling it. Alternately, you can add a gdb watchpoint to myManagedObjectContext to see when the memory is changed.

You haven’t indicated what the crash stack is when you crash. You should be focused on what memory you’re accessing at the point of the crash, and ensuring that the crash is due to a memory violation rather than an exception. Check your debugger output. Often it will tell you what’s happening.