Сбой iPhone Simulator с WebPreferences в списке тем

Question

Справочная библиотека разработчика Apple имеет класс для WebPreferences

Я искал SO, Dev Forums и Googled без каких-либо релевантных результатов.

EXC_BAD_ACCESS сигнал генерируется.

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

EDIT

Это срабатывает при нажатии UITextField, оставляя UITextField или если UITextField устанавливается в качестве первого ответчика при загрузке вида (нажатие навигационным контроллером).

Воспроизвести нелегко. Я могу пройти сто циклов запуска / отладки приложения, прежде чем это произойдет снова. И тогда это может произойти 3 раза за 5 запусков.

---

У меня есть список потоков в отладчике, который показывает несколько ссылок на WebPreferences.

Answer 1

Вы на правильном пути, если используете NSZombie . EXEC_BAD_ACCESS вызывается доступом к освобожденным объектам.

Обычно EXEC_BAD_ACCESS "вылетает" в пути кода, который вам не принадлежит. Скорее всего, ваш код создал перевыпущенный объект.

Ключевой частью использования NSZombie является запуск malloc_history в командной строке. Вы получите стек вызовов, показывающий, откуда произошел перевыпущенный объект. Например: альтернативный текст http://static.benford.name/malloc_history.png

На снимке экрана показано, что мое приложение вылетает на [NSString stringByTrimmingCharactersInSet:], но это определенно не тот, кто вызвал сбой.

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

В этом случае объект произошел из класса [JTServiceHttpRequest requestFinished], в котором я не правильно сохранил объект.

Если ничего не помогает, просмотрите все перечисленные пути кода и проверьте правильность использования правил управления памятью.

Могу поспорить, что поведение WebPreferences и UITextField не имеет отношения к краху.

Answer 2

Для любых ошибок EXC_BAD_ACCESS вы обычно пытаетесь отправить сообщение освобожденному объекту. ЛУЧШИЙ способ отследить это - использовать NSZombieEnabled .

Это работает, никогда не выпуская объект, а заключая его в «зомби» и устанавливая внутри него флаг, который говорит, что обычно он был бы выпущен. Таким образом, если вы попытаетесь снова получить к нему доступ, он все еще будет знать, что было до того, как вы допустили ошибку, и с помощью этой небольшой информации вы обычно можете вернуться назад, чтобы увидеть, в чем проблема.

Это особенно помогает в фоновых потоках, когда отладчик иногда выбрасывает любую полезную информацию.

ОЧЕНЬ ВАЖНО ЗАМЕЧАНИЕ однако, вам нужно на 100% убедиться, что это только в вашем отладочном коде, а не в коде дистрибутива. Поскольку ничего не выпущено, ваше приложение будет течь и течь и течь. Чтобы напомнить мне сделать это, я поместил этот журнал в моем appdelegate:

if(getenv("NSZombieEnabled") || getenv("NSAutoreleaseFreedObjectCheckEnabled"))
  NSLog(@"NSZombieEnabled/NSAutoreleaseFreedObjectCheckEnabled enabled!");

Если вам нужна помощь в поиске точной строки, выполните Build-and-Debug ( CMD-Y ) вместо Build-and-Run ( CMD-R ). Когда приложение падает, отладчик покажет вам, какая именно строка и в сочетании с NSZombieEnabled, вы сможете точно узнать, почему.

Answer 3

Звучит больше как ошибка авто-релиза. Возможно, вы выпускаете что-то, что вам не «принадлежит», и пул NSAutoRelease работает и пытается очистить то, что уже было выпущено?

Вы выпустили что-то, что не "распределили"? Например, вы не будете делать:

NSString *test = @"testing";
[test release];

Так как это вызовет сбой при запуске пула автоматического выпуска и попытке освободить строку NSString.

Answer 4

согласился с предыдущими респондентами по поводу NSZombie. Чаще всего это происходит, когда вы используете свой класс в качестве делегата UITextView (или любого другого класса), а также ссылаетесь на него в переменной IBOutlet. когда вы покидаете свой viewcontroller - он освобождается. но если вы не выпустили переменную IBOutlet в - (void) метод dealloc - UITextView все равно будет отправлять вызовы освобожденному делегату (вашему контроллеру представления).

Answer 5

Тот факт, что он вылетает в _integerValueForKey:, заставляет меня сильно подозревать, что он вылетает на переизданном NSNumber. Чрезмерное высвобождение NSNumber может привести к таким странным сбоям, что это почти смешно. Вот что происходит:

• Вы создаете NSNumber для целого числа "2"
• Класс NSNumber кэширует номер NSNumber
• Вы перепроизводите это
• Кэш класса NSNumber теперь указывает на плохую память
• Какой-то совершенно не связанный фрагмент кода создает NSNumber для целого числа "2"
• Класс NSNumber ищет его в своем кэше, и ....
• Взрыв

Если вы используете Snow Leopard, нажмите Cmd-Shift-A, чтобы позволить анализатору искать проблемы с управлением памятью. В противном случае отправляйтесь на охоту за использованием NSNumbers.