Сообщение Obj-C, отправленное на освобожденный объект (EXEC_BAD_ACCESS), с iOS5, ARC

Question

Я занимаюсь разработкой приложения для iOS5 с использованием ARC, и я начал получать случайные сбои EXEC_BAD_ACCESS, которые я не могу понять ... Случайно я имею в виду, что это очень непредсказуемо: иногда сбой может занять много времени, иногда короткий,и нет также ни одной конкретной кнопки / tablecell / etc.которые вызывают аварию.Любое взаимодействие с пользователем может привести к сбою приложения, но вы не можете повторить сбой.

Я попытался включить NSZombie, а также некоторые инструменты отладчика malloc.В Instruments ошибка сбоя гласит: Сообщение Objective C было отправлено освобожденному объекту (зомби) по адресу: 0x10bd1b40.И последняя часть журнала подсчета ссылок выглядит следующим образом:

475 CoursesFirstViewController  Release 2   02:23.253.631   0   UIKit   -[UINibDecoder finishDecoding]
476 CoursesFirstViewController  Release 1   02:23.253.838   0   Foundation  -[NSAutoreleasePool drain]
477 CoursesFirstViewController  Zombie  -1  02:35.752.420   0   Foundation  objectHash

2, 1, -1 - это счетчики ссылок.Я понятия не имею, почему он пропускает 0 и падает до -1, что приводит к сбою программы (все записи, кроме последней, имеют непрерывный счетчик ссылок).Также я понятия не имею, что такое objectHash.

Мое приложение состоит из нескольких функций, доступных в виде значков на главном экране.CoursesFirstViewController является одной из функций.Всегда это CoursesFirstViewController и objectHash, которые разрушают приложение, даже если я где-то еще.(Это относится к журналу выше: я вышел из CoursesFirstViewController (таким образом, возвращаясь к главному экрану моего приложения) в 02:23, но через 12 секунд, когда я был в какой-то другой функции, приложение упало)Мне нужно войти в CourseFirstViewController, немного поработать с ним, а затем перейти в другое место, чтобы продолжить использовать приложение, и через некоторое время оно просто рухнет.

Я действительно без ума от этой проблемы сейчас.Я долго искал SO и Google, но не могу найти решение.Любая помощь будет принята с благодарностью.Спасибо !!

Answer 1

@ robmayoff да, я уже это проверил, но там не увидел ничего особенно полезного.последние несколько вызовов: objectHash, hashProbe, [NSConcreteHashTable rehashAround], [NSConcreteHashTable removeItem] и т. д.

Это на самом деле несколько полезно.Это говорит нам о том, что коллекция, вероятно, NSDictionary, но, возможно, NSSet, уничтожается.Судя по вашей более ранней информации, это, кажется, автоматически выпущенная коллекция, которая создается во время процесса создания пера (так что, вероятно, ivar CoursesFirstViewController).Вот где бы я все равно искал, учитывая симптомы, но сбой, кажется, подтверждает это.

Общие рекомендации проверяют любые __bridge приведения или unsafe_unretained свойства.

Еще одна догадкачто вы назвали метод способом, который нарушает управление памятью Какао.Скорее всего, неправильное название будет иметь свойство, которое начинается с new или copy.Это, безусловно, будет проблемой, если у вас есть вызов кода ARC с неправильным названием кода не-ARC.

Answer 2

По выводам ваших инструментов я понял, что объект зомби имеет тип CoursesFirstViewController.Мы часто используем контроллер представления в качестве делегата для какого-либо другого объекта, и большинство объектов, имеющих делегаты, не сохраняют своих делегатов.

Я предполагаю, что вы не используете какие-либо свойства или переменные unsafe_unretained, илилюбые свойства retain -типа.Поэтому я предполагаю, что ни один из ваших объектов не содержит висячей ссылки на CoursesFirstViewController зомби.

Поскольку системные библиотеки должны работать с не-ARC-кодом, они не используют слабые ссылки ARC.Поэтому, если некоторый системный объект имеет CoursesFirstViewController в качестве своего делегата, а CoursesFirstViewController уничтожен, а системный объект - нет, тогда системный объект остается с висящей ссылкой на уничтоженный объект.

Такпроверьте, используете ли вы CoursesFirstViewController в качестве делегата для каких-либо системных объектов.Если это так, вы уверены, что эти объекты не переживают CoursesFirstViewController?

Answer 3

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

Если вам не повезет найти его, я прибегну к глобальному поиску «слабых» свойств наспроектируйте и перепроверьте каждый из них, чтобы убедиться, что это не то, что вы ожидаете.Это утомительно, но, честно говоря, это не займет много времени, а иногда и больше, чем одна ошибка.