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

Ответ 1

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

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

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

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

ИЗМЕНИТЬ

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

EDIT 2

Хорошо, хорошо... при дальнейшей проверке... Я нашел 2 ошибочных ссылки на libSystem.B.dylib в файле project.pbxproj, которые не были видны с помощью настроек сборки Xcode, но мне пришлось удалить с текстовым редактором!

После этого я reset базовая версия развертывания до 4.0, построенная для симулятора iOS5, и приложение запускалось без проблем.

Удивительная.

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

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

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

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

Как я выяснил, проблема была случайной. В то время как ничего, казалось, не произошло, "ниточный" навигатор Xcode рассказывал мне, что само приложение не разбилось. И я случайно нажал на "паузу" в отладчике. И вдруг он точно остановился там, где был тупик. Которая после некоторых мыслей просто логически очевидна.

Ответ 6

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

Ответ 7

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

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

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

Ответ 8

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

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

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

Ответ 9

Охрана 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 ()

Ответ 10

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

Ответ 11

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

-MZ