катастрофический отказ iPhone Simulator с WebPreferences в списке потока

Для любых ошибок 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 вы сможете точно выяснить, почему.

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

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

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

согласились с предыдущими респондентами о Nszombie. Чаще всего эта штука происходит, когда вы используете свой класс в качестве делегата UITEXTVIEW (или любого другого класса), а также обратитесь в переменную Iboutlet. Когда вы оставляете свой ViewController - он стал оформленным. Но если вы не выпустили переменную IBOutlet In - (void) DEALOC-метод - UItextView все равно отправят вызовы для выпущенного делегата (контроллер вашего представления).

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

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

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

Так как это приведет к краху, когда запустится пул Auto Release и попытаются выпустить NSString.