iOS 应用程序在使用 Xcode 4.2 和 iOS 5 进入 main() 之前崩溃

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

提问by Richard Stelling

Background

背景

After upgrading xcode4.1/ios4to xcode4.2/ios5I am experiencing crashes while the App is loading and beforeit even enters main().

将xcode4.1/ ios4升级到xcode4.2/ ios5 后，我在加载应用程序时甚至在它进入之前遇到崩溃main()。

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

我已经设置了一个断点，main()但它从未达到。

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

• 在 Xcode 4.1 中使用Base SDK4.3编译项目在iOS 4.x 和 iOS 5 上工作正常。
• 在 Xcode 4.2 中使用Base SDK5.0编译相同的项目在4.x 上运行良好，但在 iOS 5 中崩溃，无论是在模拟器上还是在设备上。

Simulator Crash

模拟器崩溃

Crashes with EXC_BAD_ACCESS

EXC_BAD_ACCESS崩溃

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

调用列表，所有系统调用，甚至main()还没有被调用。

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

我最好的猜测是加载库时出现问题，但知道如何追踪它！

Attempts at a resolution

尝试解决

1. Turned on Zombies
2. Turned on all logging
3. Added different versions of system libraries (libz.1.2.5.dylib and libz.dylib)
4. Cleaned the project
5. Deleted the App form the simulator
6. Delete the Derived Datafolder

1. 开启僵尸
2. 开启所有日志
3. 添加了不同版本的系统库（libz.1.2.5.dylib 和 libz.dylib）
4. 清理了项目
5. 从模拟器中删除了应用程序
6. 删除Derived Data文件夹

采纳答案by Mark Granoff

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.

我的部署目标是 iOS4.0。我把它改成iOS4.3，问题解决了！（当然是针对 iOS5 GM SDK 构建的。）我的应用程序现在在 iOS5 模拟器中运行。

I got this idea from an answer in another SO threadthat 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.

我从另一个 SO 线程中的一个答案中得到了这个想法，该答案说 iOS4.3 及更高版本支持 ARC。据我所知，我的应用程序不使用 ARC，也不使用它的任何依赖库。答案还提到了一些关于弱引用归零的内容，这似乎......也许是相关的，因为很多人已经成功地删除了关于对 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.

我不得不将我的基本部署目标提高到 4.0 以上，这让我有点困扰，因为这感觉就像我在削减很多潜在用户。尽管 Apple 希望每个人都能升级他们的设备，但很多人并没有这样做。那好吧。

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!

值得一提的是，这个项目最初是在 Xcode3 下完成的，所以项目本身可能只是一些奇怪的东西，既不需要又会导致这个问题。但如果我能找到它，我会死的！

EDIT 2

编辑 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!

好吧，好吧……经过进一步检查……我在我的 project.pbxproj 文件中发现了 2 个对 libSystem.B.dylib 的错误引用，这些引用在 Xcode 的构建设置中是不可见的，但我必须用文本编辑器！

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

执行此操作后，我将基本部署版本重置为 4.0，为 iOS5 模拟器构建，并且应用程序运行没有问题。

Amazing.

惊人的。

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

教训：永远不要低估项目文件中出现垃圾的可能性。

EDIT 3

编辑 3

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

project.pbxproj在 Xcode 项目包内的文件中删除这些行的 3 次出现（右键单击并显示包内容）。

回答by colbadhombre

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

我正在玩方案诊断，并通过意外设置“启用 Guard Malloc”获得了完全相同的行为。我的目标是 4.3，并在 5.0 模拟器上的 ARC 下运行。当从模拟器启动时，应用程序可以正常运行，只是不能从 XCode 启动。转到 Product->Edit Scheme...，选择左侧表格中的“Run”项，然后选择右侧的“Diagnostics”选项卡。取消选中“启用 Guard Malloc”。

回答by Phillip Kast

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.x 部署目标针对 iOS 4.x 进行构建。无论出于何种原因，它现在在模拟器中完全损坏了。

回答by matt fryer

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.

我尝试了 rjstelling 和 MarkGranoff 的帖子中的所有内容，但无济于事。我现在可以通过在我的调试方案中关闭 Guard Malloc 来重现它不会发生。Guard Malloc 开启——崩溃，关闭——没有崩溃。我从来没有在设备上遇到过问题，只有模拟器。我首先应用了上面帖子中的修复程序，所以我不知道如果没有这些更改，这是否会解决问题。希望这对其他人有帮助。

回答by onekiloparsec

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

但是，此处的答案中描述的解决方案对我不起作用，因为我在 project.pbxproj 中没有发现与“弱”相关的问题

However, I found that the cause of my problem was a deadlock in an +(void)initializemethod 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.

但是，我发现我的问题的原因是+(void)initialize从主线程调用的方法中出现了死锁。在这种方法中，我正在调用dispatch_sync(dispatch_get_main_queue(), ^{[some block code]}). 将其更改为 a dispatch_async（注意“a”）解决了我的问题。

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.

我发现这个问题的方式是偶然的。虽然似乎什么也没发生，但 Xcode 的“线程”导航器告诉我应用程序本身没有崩溃。我不小心点击了调试器中的“暂停”。突然，它在僵局所在的地方停了下来。经过一些思考，这在逻辑上是显而易见的。

回答by Alexander

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

我在逻辑单元测试中遇到了类似的问题（在 iOS 模拟器中运行独立的目标而不依赖于主应用程序），在我的情况下问题出在 lldb 中，这里有更多详细信息：
逻辑单元测试崩溃

回答by Mojo66

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

main.m当链接的框架没有被复制时，应用程序可能会在进入前崩溃，例如因为项目使用 Carthage 并且缺少Run Script构建阶段/usr/local/bin/carthage copy-frameworks。

回答by Foti Dim

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

在我的情况下，它是-objc标志Other Linker Flags。我不得不删除它，它就像一个魅力。

回答by Evan Schoenberg

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

您可以有条件地将链接器标志应用于 iOS SDK，但不能应用于 XCode 4 中的 iPhone 模拟器。

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.

选择Other Linker Flags，点击Add Build Setting，选择Add Conditional Setting，然后为iOS SDK应用-weak_library /usr/lib/libSystem.B.dylib。

This lets simulator builds still work.

这让模拟器构建仍然有效。

回答by Ben Challenor

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

Guard malloc 也是我的问题。可能是因为我使用的是 libxml2.2.7.3.dylib。

This questiondescribes 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.

这个问题描述了同样的崩溃，但他很幸运能够开启保护 malloc，所以很明显是什么导致了崩溃。将 Xcode 升级到 4.2 后，我刚刚崩溃。

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

我想包括堆栈跟踪，以便它是 Googleable。我无法找到此页面。

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