问题
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.
- Compiling the project in Xcode 4.1 with a
Base SDKof 4.3 works fine on iOS 4.x and iOS 5. - Compiling the same project in Xcode 4.2 with a
Base SDKof 5.0 works fine on 4.x but crashes in iOS 5, both on the simulator and on a device.
Simulator Crash
Crashes with EXC_BAD_ACCESS
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 Datafolder
回答1:
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).
回答2:
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.
回答3:
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".
回答4:
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.
回答5:
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.
回答6:
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
回答7:
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?
回答8:
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.
回答9:
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 ()
回答10:
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.
回答11:
In my case it was the -objc flag in Other Linker Flags. I had to remove that and it worked like a charm.
回答12:
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
来源：https://stackoverflow.com/questions/7710163/ios-app-crashing-before-entering-main-with-xcode-4-2-ios-5