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

I have set a break point in main() but it is never reached.

main() break point

Compiling the project in Xcode 4.1 with a Base SDK of 4.3 works fine on iOS 4.x and iOS 5.
Compiling the same project in Xcode 4.2 with a Base SDK of 5.0 works fine on 4.x but crashes in iOS 5, both on the simulator and on a device.

Simulator Crash

iOS 5 Simulator LLDB Crash Xcode 4.2 Output

Crashes with EXC_BAD_ACCESS

Stack calls

List of calls, all system calls, not even the main() has not been called yet.

My best guess is a problem loading a library, but have know idea how to track it down!

Attempts at a resolution

Turned on Zombies
Turned on all logging
Added different versions of system libraries (libz.1.2.5.dylib and libz.dylib)
Cleaned the project
Deleted the App form the simulator
Delete the Derived Data folder

Did you clean the project? Sometimes Xcode behaves very strangely — Jaffa, Oct 10 '11 at 08:32
@Geoffroy Yes - with no luck. Updated question with that info. — Richard Stelling, Oct 10 '11 at 08:45
That seems weird that in crashes _before_ main... Did you set a breakpoints? — Jaffa, Oct 10 '11 at 08:53
@Geoffroy I did! (Forgot to add it to the question), noW added with screen shot. — Richard Stelling, Oct 10 '11 at 09:03
Fwiw, I see the very same behavior with a very complex app. The app apparently builds and links fine under Xcode4.2. When launched in the iOS5 simulator, it crashes in exactly the way you describe. When launched in the iOS4.3 simulator, the app actually runs, but I can create a memory corruption crash every time. The code is unchanged from that which we used to submit to the App Store months ago (and built at that time with Xcode3.2.6). There is something very odd here, indeed. — Mark Granoff, Oct 10 '11 at 20:35
@MarkGranoff my project is large too. 4 project dependancies and 5 3rd party libs. — Richard Stelling, Oct 10 '11 at 22:10
@rjstelling Ah! Indeed. Mine has 11 subprojects and 6 third-party (open source) libraries. G-d help us! :-) — Mark Granoff, Oct 10 '11 at 23:25
Please include stack traces as text; I couldn't find this page easily with Google! — Ben Challenor, Nov 30 '11 at 16:50

score 10 · Accepted Answer · edited Jun 20 '20 at 09:12

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

Xcode project edit

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

show package contents

Had to do all these to get it to work, have edited with screen shot to ilistrate. Thanks! — Richard Stelling, Oct 13 '11 at 18:41
Team effort, my friend... a team effort! I am glad to be making forward progress again! — Mark Granoff, Oct 13 '11 at 18:52
Chiming in to say, I also found the weak blocks library reference in my project. It was visible in Xcode 4.2, though, but removing the weak reference fixed this hang. — Héctor Ramos, Dec 14 '11 at 18:28

score 2 · Answer 2 · answered Oct 10 '11 at 20:24

Check your linker flags. Some libraries you might have been using required a flag like this:

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

The weak linking allowed building against iOS 4.x with a 3.x deployment target. For whatever reason, it's completely broken in the simulator now.

score 2 · Answer 3 · answered Nov 29 '11 at 20:23

2

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".

answered Nov 29 '11 at 20:23

colbadhombre

803
8
11

Drat — I ran into the same problem, not using ARC in my case, but I turned on Guard Malloc to try to track down another problem (SIGABRT in UIApplicationMain). That led me to this thread, and the many others like it; but there are no weak_library flags nor references to libSystem anywhere in my project files. Found this answer, and sure enough, turning off Enable Guard Malloc gets rid of the mig_get_reply_port hang (and back to my crash inside GSRegisterPurpleNamedPort -- back to searching for that!). – Joe Strout Feb 24 '12 at 16:25

score 1 · Answer 4 · answered Nov 13 '16 at 22:23

1

An app crashing before entering main.m can happen when a linked framework doesn't get copied, for example because the project uses Carthage and the Run Script build phase /usr/local/bin/carthage copy-frameworks is missing.

answered Nov 13 '16 at 22:23

Mojo66

1,109
12
21

score 1 · Answer 5 · answered Oct 26 '11 at 23:17

I tried everything in rjstelling and MarkGranoff's posts to no avail. I can now reproducibly cause it to not happen by turning off Guard Malloc on my debug scheme. Guard Malloc on--crash, off--no crash. I never had the problem on the device only the simulator. I applied the fixes in the post above first so I don't know if this would have fixed the problem without those changes or not. Hope this helps someone else.

score 1 · Answer 6 · answered Jan 31 '12 at 16:07

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.

score 1 · Answer 7 · edited May 23 '17 at 12:13

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

edited May 23 '17 at 12:13

Community

1
1

answered Feb 24 '12 at 09:03

Alexander

780
1
8
22

I'm running into something similar. My unit tests crash only when using lldb. – ThomasW Feb 28 '12 at 07:01

score 0 · Answer 8 · answered Sep 15 '18 at 10:52

0

In my case it was the -objc flag in Other Linker Flags. I had to remove that and it worked like a charm.

answered Sep 15 '18 at 10:52

Foti Dim

1,303
13
19

score 0 · Answer 9 · answered Oct 10 '11 at 20:30

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?

score 0 · Answer 10 · answered Nov 11 '11 at 03:39

You can apply the linker flag conditionally to iOS SDKs but not the iPhone Simulator in XCode 4.

Select Other Linker Flags, click Add Build Setting, choose Add Conditional Setting, and apply -weak_library /usr/lib/libSystem.B.dylib just for iOS SDK.

This lets simulator builds still work.

score 0 · Answer 11 · edited May 23 '17 at 12:01

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

score -1 · Answer 12 · answered Oct 10 '11 at 09:12

-1

I seem to remember having had a similar crashing bug prior to main() being called and I tracked it to a mismatch between IBOutlets declared in app delegate vs in my nibs. Go through and check your outlets to see if any are somehow misconfigured.

-mz

answered Oct 10 '11 at 09:12

mahboudz

39,196
16
97
124

I use very few .xib in the project. I have checked them all and they seem to be ok. – Richard Stelling Oct 10 '11 at 09:32
Try making a copy of your NIB, and then deleting all the objects in it. Or unlink the NIBs from your target and see whether you get any further. The problem has to be something that is happening before your code gets called, so the other place to check is whether you are using the right platform and processor settings in your build settings. – mahboudz Oct 10 '11 at 20:25