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

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


iphone crash compiler-construction
person itsaboutcode    schedule 18.09.2009    source источник
comment
Возможно, вам повезет больше, если вы опубликуете пример такой трассировки стека.   -  person HalliHax    schedule 18.09.2009
comment
Ну я не могу указать здесь конкретный пример, это происходит каждый раз, когда программа вылетает!   -  person itsaboutcode    schedule 18.09.2009

Ответы (3)


arrow_upward
3
arrow_downward

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

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

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

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

if(getenv("NSZombieEnabled") || getenv("NSAutoreleaseFreedObjectCheckEnabled"))
  NSLog(@"NSZombieEnabled/NSAutoreleaseFreedObjectCheckEnabled enabled!");
person coneybeare    schedule 18.09.2009
comment
Спасибо, я думаю, что это решит некоторые из моих проблем, это будет здорово, если вы ищете возможные утечки памяти, но мне было интересно, будет ли это полезно в случаях сбоев? - person itsaboutcode; 18.09.2009
comment
это полезно только в случаях сбоев - случаях сбоев, которые происходят из-за проблем с памятью, а это большинство из них. - person coneybeare; 18.09.2009

arrow_upward
1
arrow_downward

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

Функция, которая у меня есть в моем .profile, чтобы помочь мне запустить команду:

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

По сути, вы помещаете пакет приложения, файл dsym, сгенерированный при сборке, и журнал сбоев в один и тот же каталог, а затем запускаете «dysm [имя файла журнала сбоев]», чтобы символы правильно отображались в трассировке стека.

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

person Kendall Helmstetter Gelner    schedule 18.09.2009

arrow_upward
0
arrow_downward

Список задач:

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

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

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

person zaph    schedule 18.09.2009