Сбой приложения iOS перед входом в main() с Xcode 4.2 и iOS 5

Какова ваша цель развертывания?

Целью моего развертывания была iOS4.0. Я изменил его на iOS4.3, и проблема решена! (Конечно, на основе iOS5 GM SDK.) Мое приложение теперь работает в симуляторе iOS5.

Я получил эту идею от ответ в другом потоке SO, в котором говорится, что ARC поддерживается в iOS4.3 и выше. Насколько я могу судить, мое приложение не использует ни ARC, ни какие-либо из его зависимых библиотек. В ответе также говорилось об обнулении слабых ссылок, что казалось... возможно, уместным, поскольку многим людям удалось удалить определенные директивы компоновщика, касающиеся слабых ссылок на libSystem.B.dylib.

Меня немного беспокоит то, что мне приходится поднимать базовую цель развертывания выше 4.0, потому что мне кажется, что я отсекаю много потенциальных пользователей. Несмотря на надежду Apple на то, что все всегда будут обновлять свои устройства, многие этого не делают. Ну что ж.

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

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

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

Ну-ну-ну... при дальнейшем осмотре... я обнаружил 2 ошибочные ссылки на libSystem.B.dylib в моем файле project.pbxproj, которые не были видны через настройки сборки Xcode, но которые мне пришлось удалить вручную с помощью Текстовый редактор!

Сделав это, я сбросил базовую версию развертывания на 4.0, созданную для симулятора iOS5, и приложение заработало без проблем.

Удивительный.

Урок: никогда не недооценивайте вероятность того, что в вашем файле проекта будет мусор.

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

Удаление 3 вхождений этих строк в project.pbxprojfile внутри пакета проекта Xcode (щелкните правой кнопкой мыши и отобразите содержимое пакета).

Проверьте свои флаги компоновщика. Некоторые библиотеки, которые вы могли использовать, требовали такого флага:

-weak_library /usr/lib/libSystem.B.dylib

Слабое связывание позволило выполнить сборку против iOS 4.x с целью развертывания 3.x. По какой-то причине он полностью сломан в симуляторе сейчас.

Я играл с диагностикой схемы и получил точно такое же поведение, случайно включив «Enable Guard Malloc». Я нацелился на 4.3 и работал под ARC на симуляторе 5.0. Приложение будет работать нормально при запуске из симулятора, но не из XCode. Перейдите в Продукт->Редактировать схему..., выберите пункт "Выполнить" в таблице слева, а затем вкладку "Диагностика" справа. Снимите флажок «Включить Guard Malloc».

Я пробовал все в сообщениях rjstelling и MarkGranoff безрезультатно. Теперь я могу воспроизводимо предотвратить это, отключив Guard Malloc в моей схеме отладки. Охраняйте Мэллока - авария, авария - нет. У меня никогда не было проблем на устройстве, только на симуляторе. Сначала я применил исправления в сообщении выше, поэтому я не знаю, решило бы это проблему без этих изменений или нет. Надеюсь, это поможет кому-то еще.

У меня была точно такая же диагностика, но решение было совершенно другим.

Однако решение, описанное в ответах здесь, не сработало для меня, потому что я не нашел проблем, связанных со «слабыми» в моем проекте.pbxproj

Однако я обнаружил, что причиной моей проблемы была взаимоблокировка в методе +(void)initialize, вызываемом из основного потока. В этом методе я вызывал dispatch_sync(dispatch_get_main_queue(), ^{[some block code]}). Изменение этого на dispatch_async (обратите внимание на «а») решило мою проблему.

То, как я обнаружил проблему, было случайным. Хотя, казалось, ничего не произошло, навигатор «потоков» Xcode сообщил мне, что само приложение не разбилось. И я случайно нажал на "паузу" в отладчике. И вдруг он остановился именно там, где был тупик. Что после некоторых размышлений просто логически очевидно.

У меня была аналогичная проблема с тестированием логического модуля (запуск отдельной цели без зависимости от основного приложения в симуляторе iOS), в моей ситуации проблема была в lldb, здесь подробнее:
Сбой модульных тестов логики

Сбой приложения перед входом в main.m может произойти, если связанная платформа не скопирована, например, потому что проект использует Carthage, а Run Script фаза сборки /usr/local/bin/carthage copy-frameworks отсутствует.

Xcode 4.2 все еще имеет некоторые шероховатости от моего использования. Полное удаление и переустановка исправили проблему, которая у меня была (она застряла на «Прикреплении», и ни одно из решений в «официальной» ветке SO не помогло). Хотя, может быть, немного экстремально.

Выберите проект верхнего уровня в File Navigator и перейдите на вкладку Build Phases. Разверните раздел «Связать двоичный файл с фреймворками». Существуют ли фреймворки, которые не предоставляются Apple? Являются ли они необязательными или обязательными? И требует ли какой-либо из ваших кодов дополнительных фреймворков?

Чтобы помочь больше, не могли бы вы опубликовать все сообщения журнала, которые в настоящее время скрыты всплывающим окном стека вызовов?

Вы можете условно применить флаг компоновщика к iOS SDK, но не к симулятору iPhone в XCode 4.

Выберите «Другие флаги компоновщика», нажмите «Добавить параметр сборки», выберите «Добавить условный параметр» и примените -weak_library /usr/lib/libSystem.B.dylib только для iOS SDK.

Это позволяет сборкам симулятора по-прежнему работать.

Guard malloc тоже был проблемой для меня. Возможно, потому что я использую libxml2.2.7.3.dylib.

Этот вопрос описывает тот же сбой, но ему посчастливилось включить защиту malloc, так что было очевидно, что вызвало сбой. Я только что получил сбой после обновления Xcode до 4.2.

Я хотел бы включить трассировку стека, чтобы она была доступна для Google. У меня возникли проблемы с поиском этой страницы.

#0  0x00000000 in <????> ()
#1  0x99924ef3 in mig_get_reply_port ()
#2  0x9991e70c in mach_ports_lookup ()
#3  0x0141c124 in _xpc_domain_init_local ()
#4  0x01419eb1 in _libxpc_initializer ()
#5  0x8fe2a15b in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE ()
#6  0x8fe29cc0 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()
#7  0x8fe27220 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
#8  0x8fe271b6 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
#9  0x8fe271b6 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
#10 0x8fe271b6 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
#11 0x8fe271b6 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
#12 0x8fe281c0 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE ()
#13 0x8fe1c626 in __dyld__ZN4dyld24initializeMainExecutableEv ()
#14 0x8fe20ef2 in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
#15 0x8fe1a2ef in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKclS2_ ()
#16 0x8fe1a063 in __dyld__dyld_start ()

В моем случае это был флаг -objc в Other Linker Flags. Мне пришлось удалить это, и это сработало как шарм.

Кажется, я помню, что у меня была похожая ошибка сбоя до вызова main(), и я отследил ее до несоответствия между IBOutlets, объявленными в делегате приложения, и в моих перьях. Пройдите и проверьте свои розетки, чтобы увидеть, не настроены ли они как-то неправильно.

-mz