iOS App crashing before entering main() with Xcode 4.2 & iOS 5

Question

Background

After upgrading xcode4.1/ios4 to xcode4.2/ios5 I am experiencing crashes while the App is loading and before it even enters main().

Answer 1

I had similar problem with logic unit testing (running separate target without dependency on the main app in the iOS simulator), in my situation problem was in lldb, here is more details:
Logic unit tests crash

Answer 2

Guard malloc was the problem for me too. Probably because I'm using libxml2.2.7.3.dylib.

This question describes the same crash, but he was lucky enough to be turning guard malloc on, so it was obvious what caused the crash. I just got the crash after upgrading Xcode to 4.2.

I'd like to include the stack trace so that it is Googleable. I had trouble finding this page.

#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 ()

Answer 3

I had the exact same diagnostic, but the solution was entirely different.

However, the solution described in the answers here didn't work for me, because I found no "weak"-related issues in my project.pbxproj

However, I found that the cause of my problem was a deadlock in an +(void)initialize method called from the main thread. In this method, I was calling dispatch_sync(dispatch_get_main_queue(), ^{[some block code]}). Changing this to a dispatch_async (note the "a") solved my problem.

The way I discovered the issue was accidental. While nothing seemed to happen, the "thread" navigator of Xcode was telling me that the app itself wasn't crashed. And I accidentaly clicked on "pause" in the debugger. And suddenly it stopped exactly where the deadlock was. Which after some thoughts is just logically obvious.

Answer 4

Xcode 4.2 still has some rough edges from my usage. A complete removal and re-install fixed an issue I had (it was stuck on "Attaching" and none of the solutions on the "official" SO thread helped). Might be a bit extreme though.

Select the top-level project in the File Navigator and go to the Build Phases tab. Expand "Link Binary with Frameworks" section—are there any frameworks that aren't Apple-provided? Are they Optional or Required? And does any of your code required any additional frameworks?

To help more could you post all the log messages that are currently being obscured by the call stack popup?

Answer 5

I was playing around with the scheme diagnostics, and got this exact same behavior by accidentally setting "Enable Guard Malloc" on. I had targeteted 4.3 and was running under ARC on the 5.0 Simulator. The app would run fine when launched from the simulator, just not from XCode. Go to Product->Edit Scheme..., select the "Run" item in the table to the left, and then the "Diagnostics" tab to the right. Uncheck "Enable Guard Malloc".

Answer 6

What is your deployment target?

My deployment target was iOS4.0. I changed it to iOS4.3 and the issue is resolved! (Building against iOS5 GM SDK, of course.) My app now runs in the iOS5 simulator.

I got this idea from an answer in another SO thread that said ARC is supported in iOS4.3 and above. My app doesn't use ARC, nor do any of it's dependent libraries, as far as I can tell. The answer also said something about weak reference zeroing, which seemed... perhaps relevent since a lot of people have had success in removing specific linker directives concerning weak references to libSystem.B.dylib.

It bothers me a little that I have to move up my base deployment target beyond 4.0 because that feels like I am cutting out a lot of potential users. Despite Apple's hope that everyone will always upgrade their devices, many people do not. Oh well.

EDIT

It's worth mentioning that this project was originally done under Xcode3, so there is likely just some bizarre cruft in the project itself that is both unneeded and causing this problem. But I'll be damned if I can find it!

EDIT 2

Well, well, well... upon further inspection... I found 2 errant references to libSystem.B.dylib in my project.pbxproj file that were not visible through Xcode's build settings, but that I had to remove by hand with a text editor!

Once doing this, I reset the base deployment version to 4.0, built for the iOS5 simulator, and the app ran without issue.

Amazing.

The lesson: Never underestimate the chances for there to be garbage in your project file.

EDIT 3

Removing the 3 occurrences of these lines in the project.pbxprojfile inside the Xcode project package (right click and show package contents).