приложение прекрасно работает с отладочной сборкой, но сбой при сборке релиза, каковы могут быть возможные причины?

Question

У меня Xcode 4.3.1, iOS 5.1, и ARC включен для сборки моего приложения.

Теперь приложение отлично работает в отладочной сборке, но аварийно завершает работу при выпуске сборки.В чем может быть причина разницы?Я просто полагаюсь на ARC для управления ресурсами.Я посмотрел на журнал сбоев, он показывает, что память, на которую ссылались, уже была освобождена.Каковы распространенные ловушки, которые могут вызвать проблемы при розничной сборке при использовании ARC?

Вот что я получил из журнала сбоев

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x6f636552
Crashed Thread:  0

РЕДАКТИРОВАТЬ

Цель развертывания приложения - iOS 5.0.Я использую интернет-соединения, текущий сбой происходит в то время, когда «рендеринг» данных, возвращенных из веб-службы, чтобы показать на UITableViewController.Все приложение использует ARC, за исключением нескольких исходных файлов от сторонних производителей, для которых у меня отключен ARC.

Answer 1

Всякий раз, когда это происходит со мной, это происходит потому, что сборки релизов более агрессивны в отношении устранения слабых ссылок. Если вы по ошибке присваиваете что-то слабому свойству (например, если вы добавляете подпредставления, к которым у вас также будут слабые ссылки) до того, как у вас есть на них сильные ссылки, это может сработать при отладке и завершиться неудачно при выпуске. Например (псевдокод)

@property (weak) UILabel * label;
...
self.label = [[UILabel alloc] init]; 
[self.view addSubview:self.label];
...
self.label.text = @"hello";

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

Answer 2

У вас есть другая цель для выпуска и отладки? Проверьте, правильно ли указаны все файлы для цели выпуска.

В нашем случае целевая версия не видела категорию на UIButton. Специальная сборка шла хорошо, пока кто-то не вызвал метод, реализованный этой категорией. Поскольку мы не хранили архив из специальной сборки, отладки при сбое не было. (извлеченный урок)

Не уверен, указан ли он как EXC_BAD_ACCESS в журнале сбоев, но может помочь кому-то идентифицировать их аварийное завершение.

Answer 3

Возможно, у меня нет ответа, но я собираюсь перечислить несколько догадок, чтобы вы попробовали:

• Убедитесь, что вы не передаете объекты в методы без «дескриптора» на нем.Твоя сторона.И примером будет передача экземпляра класса обработчика методу, который ожидает делегата.Метод не сохраняет этот экземпляр, поэтому он освобождается еще до того, как вызовет его.
• Проверьте макросы прекомпилятора, чтобы они были безопасны как для сборок DEBUG, так и для RELEASE.Хорошим примером является наличие оператора if над макросом, который удаляется в сборках релиза, а оператор if не покрывает его фигурными скобками.
• Если вы включаете / отключаете определения компилятораопределенные части вашего кода (с помощью #if условий) убедитесь, что необходимые параметры установлены в вашей конфигурации сборки.

Если я смогу подумать о большем, я постараюсь добавить их.