Сбой приложения при втором выборе той же строки - PullRequest
0 голосов
/ 19 января 2010

У меня возникла проблема с приложением данных ядра iPhone, над которым я работаю. У меня есть таблица, в которой перечислены объекты. Если я выберу один из этих объектов, я перейду к новому ViewController, который показывает детали для объекта.

В подробном представлении у меня есть кнопка возврата, которая возвращает меня к основному списку.

Я могу выбрать любое количество строк, и он покажет мне подробный вид для каждой. Однако, если я пытаюсь выбрать строку, которую я уже выбрал, она вылетает с

Программа получила сигнал: «EXC_BAD_ACCESS».

Я добавил несколько точек останова, попытался отследить это и нашел следующее в методе tableView cellForRowAtIndexPath ...

Первый раз для каждого объекта, когда я делаю MyEntity * thingamy = [fetchedResultsController objectAtIndexPath: indexPath] Вещи действительны и установлены на действительные вещи. В GDB я могу установить точку останова на этом этапе и сделать

по штуке и я получаю ожидаемый результат.

Однако во второй раз, когда я выбираю конкретную строку (например, выбираю строку 0, возвращаюсь назад, снова выбираю строку 0), вещь не настроена правильно.

Я могу просмотреть любое количество других строк, но как только я пытаюсь выбрать строку, я уже просмотрел детали для этого.

Если у меня есть точка останова, и я пытаюсь выполнить po thingamy после ее установки, я получаю следующее:

Программа получила сигнал EXC_BAD_ACCESS, Не удалось получить доступ к памяти. Причина: KERN_PROTECTION_FAILURE по адресу: 0x00000020 0x92ca3ed7 в objc_msgSend ()

Есть идеи, почему fetchedResultsController возвращает действительный объект при первом вызове, а не при втором?

UPDATE

Спустя несколько дней я уверен, что проблема не в том, что fetchedResultsController не имеет значения. Я включил режим NSZombieEnabled, и там ничего нет.

Кроме того, я могу получить другие объекты из fetchedREsultsController, но не тот, к которому я уже обращался.

Например, я могу получить [fetchedResultsController objectAtIndexPath: [NSIndexPath indexPathForRow: 0 inSection: 0] и отобразить это в моем следующем виде.

Когда я возвращаюсь назад и возвращаюсь к своему родительскому представлению, я могу тогда получить объект в indexPathForRow: 0 inSection: 1 и отобразить это.

Возвращаясь к началу снова, я пытаюсь получить indexPathForRow: 0 inSection: 0, и он вылетает с EXC_BAD_ACCESS.

В таблице с 100 строками я могу получить каждую строку один раз, но любая попытка получить одну и ту же строку дважды терпит неудачу, даже если эти попытки выполняются одна за другой.

Ответы [ 4 ]

1 голос
/ 20 января 2010

У меня была именно эта проблема с NSFetchedResultsController. Я решил это путем включения NSZombieEnabled в Xcode . В моем случае оказалось, что я перевыпускаю NSFetchedResultsController.

Это сработало в первый раз, когда я загрузил данные, но потом я выпускал их, не осознавая этого. В следующий раз я выпустил тот же экземпляр, который уже выпустил, и он вылетит.

Если проблемы не исчезли, опубликуйте код инициализации NSFetchedResultsController.

0 голосов
/ 14 февраля 2010

Я наконец нашел ответ на этот вопрос!

В моем разделе, посвященном dealloc, я освободил несколько переменных вместо того, чтобы их освобождатьТеперь, когда я изменил их на релиз, все работает как положено.

0 голосов
/ 20 января 2010

У вас реализован следующий метод?

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

Возможно, добавить туда точку останова и посмотреть, меняется ли содержимое? Учитывая разговор NSFetchResultsController, я подумал, что вы можете быть в сценарии, где это может помочь.

0 голосов
/ 19 января 2010

Похоже, когда вы возвращаетесь, список фактически был уничтожен, и указатели больше не ссылаются на действительные адреса памяти. У вас есть что-то, что располагает списком?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...