Отчет о сбое программы IPhone и стек, показанный компилятором, совершенно бесполезен!

Question

В большинстве случаев, когда происходит сбой программы Iphone, компилятор показывает стек, полный «нет», но эти «нет» не имеют для меня никакого смысла. Очень редко он указывает, где проблема может быть, и в основном это бесполезные нет. Как вы можете быть уверены, что когда ваша программа аварийно завершает работу во время разработки / тестирования, она показывает, в каком месте это вызвало этот сбой?

Answer 1

Жизнь моего iPhone была ужасной, пока я не нашел NSZombieEnabled . Добавив этот флаг в ваш исполняемый файл, он поможет вам увидеть любые проблемы с памятью, сообщив вам, как называется ошибочный объект.

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

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

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

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

Answer 2

Ключевое слово, которое вы ищете, это «символ». Если у вас есть журнал сбоев от устройства, вы должны обозначить его символом солнца, чтобы трассировка стека дала вам номера строк.

В моем файле .profile есть функция, которая помогает мне выполнить команду:

function desym
{
/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash -A -v $1 | more
}

Обычно вы помещаете комплект приложений, файл dsym, сгенерированный при сборке, и журнал сбоев в тот же каталог, а затем запускаете "dysm [CrashLog File Name]", чтобы символы правильно отображались в трассировке стека.

Обратите внимание, что должен быть тем же исполняемым файлом и файлом dysm, который вызвал сбой! Каждый раз, когда вы перекомпилируете, расположение вещей может меняться.

Answer 3

Чем заняться:

1) Отладка с точкой останова на

2) Добавить глобальную точку останова: objc_exception_throw

Тогда посмотрите в окне отладчика