NSZombieEnabled не сообщает тип объекта, вызывающего ошибку EXC_BAD_ACCESS

У меня случился сбой, который происходит по какой-то причине внутри UIKit; ошибка EXC_BAD_ACCESS происходит примерно так же, как 8 вызовов в вызове rejectModalViewController. Я попытался включить NSZombieEnabled для моего исполняемого файла, но журнал консоли печатает ту же ошибку, независимо от того, включены или нет зомби, и я не знаю, какой объект вызывает эту проблему. Есть ли что-то, что мне не хватает, что мне нужно сделать, чтобы консоль напечатала правильную информацию?NSZombieEnabled не сообщает тип объекта, вызывающего ошибку EXC_BAD_ACCESS

источник

2009-10-27 Kevlar

Нам действительно нужно увидеть трассировку стека на этом. Либо вы выпускаете что-то в dealloc, которое уже освобождается, либо вы вызываете то, что использует что-то, что было освобождено, или, возможно, что-то еще пытается перезвонить к утерянному модальному виду после его увольнения. –

Подробнее об использовании Зомби here.

Запустите это в gdb. Когда вы получите EXC_BAD_ACCESS, посмотрите на стек в этой точке (используйте команду gdb или запустите отладчик Xcode GUI). Если у вас все еще есть проблемы, отправьте стек в исходный вопрос.

Также зомби помогут вам, если вы имеете дело с NSObjects. Если вы используете низкоуровневые malloc/бесплатные подпрограммы, зомби не покупают вам ничего для этих распределений.

источник

2009-10-27 18:59:31 nall

Ваше последнее утверждение было, вероятно, так. Это было что-то сбой в коде Core Animation, который разбился, потому что некоторые предыдущие действия в приложении прекратили любую анимацию; к счастью, некоторые образованные предположения позволили мне решить проблему. – Kevlar

Ссылка, названная «здесь» в сообщении @ nall, приводит к странице CocoaDev, которая была вокруг навсегда. Что не обязательно плохо в мире UNIX, но утомляйтесь копированием настроек ~/.gdbinit, которые так задумчиво предоставляет AdhamhFindlay. Я сделал это где-то около Xcode 2.2, и в это время они, казалось, не навредили и очень мало пользы, но с тех пор я их удалил. Если вы почувствуете необходимость изменения любых настроек gdb, используйте Xcode Target Info >> Build settings для этого. Что касается NSZombieEnabled, мне часто кажется, что он так же полезен, как существа, которым он назван в честь. –

В чем смысл использования .gdbinit? Установка настроек исключительно в Xcode предотвращает gdb от их соблюдения при работе за пределами Xcode (что, как мне часто случается) – nall

-1

Похоже, что что-то перевыполнено в вашем Modal View Controller. Начните с комментариев новых строк до тех пор, пока он не перестанет ломаться.

источник

2009-10-27 18:34:18 coneybeare

Я знаю, но это не отвечает на вопрос, почему NSZombieEnabled не работает так, как рекламируется, что сделает отладку намного проще. – Kevlar

Случайно комментируя «новые» строки - это ужасно неэффективный способ отладки этого. – nall

Возможно, для вас, но для того, как я пишу свой код (меньше), он довольно эффективен. – coneybeare

Одна вещь, которую я узнал в прошлый уик-энд, когда NSZombieEnabled, похоже, не работает вообще - убедитесь, что вы не передаете какой-либо объект в какой-то код.

В моем случае я возвращал NSString как «string» вместо @ «string». Это означало, что я переписывал объект NSString с помощью c-строки. Когда я позже попытался написать новое значение в этом объекте, я получил BAD_ACCESS. NSZombie's не мог помочь b/c, это был не объект, который я пытался перезаписать, но эту c-строку.

Как в стороне, обрабатывайте все предупреждения как ошибки в XCode - хотелось бы, чтобы они отображались в RED в графическом интерфейсе IDE - их легко пропустить иногда.

источник

2009-10-28 20:31:08 Jason

Следующее, что нужно сделать, чтобы они отображались в RED, - это проверка «Обработка предупреждений как ошибок» в разделе «Сборка» цели Информация. –

NSZombieEnabled не сообщает тип объекта, вызывающего ошибку EXC_BAD_ACCESS

ответ

Смежные вопросы