XCode 6.1 和 6.1.1 在调试器断点（模拟器）上崩溃

XCode 6.1 and 6.1.1 Crashes on Debugger Breakpoint (Simulator)

提问by BK-

I, like many others, have had issues with XCode 6+ crashing. I get the SourceKit crashes as well as full application crashes. On a whim I figured I'd try 6.1.1 (developer member center) and it was worse, a debugger breakpoint now results in a a full application crash. So I said forget it and went back to 6.1, but I still have crashes when putting in a debugger breakpoint.

我和许多其他人一样，遇到了 XCode 6+ 崩溃的问题。我收到 SourceKit 崩溃以及完整的应用程序崩溃。一时兴起，我想我会尝试 6.1.1（开发人员会员中心），但更糟糕的是，调试器断点现在会导致应用程序完全崩溃。所以我说忘记它并返回到 6.1，但在放入调试器断点时我仍然崩溃。

Apparently this crash with breakpoint only affects the Simulator, physical devices set and stop at breakpoints without an issue. Weird!

显然，这种断点崩溃只会影响模拟器，物理设备在断点处设置和停止没有问题。奇怪的！

It's absolutely maddening!! Anyone else getting this?

这绝对令人抓狂！！还有人收到这个吗？

Things I've tried:

我尝试过的事情：

• remove /Application/Xcode.app/ & ~/Library/Developer/*
• cleaning the project
• rebooted my laptop
• breakpoint for execution on a physical device (<<<<====== This works!!!)
• slaughtering a chicken and spreading it's blood all over

• 删除 /Application/Xcode.app/ & ~/Library/Developer/*
• 清理项目
• 重新启动了我的笔记本电脑
• 在物理设备上执行的断点（<<<<====== 这有效！！！）
• 屠宰一只鸡，把它的血洒在身上

Head of the stack trace:

堆栈跟踪的头部：

Process:         Xcode [7904]
Path:            /Applications/Xcode.app/Contents/MacOS/Xcode
Identifier:      com.apple.dt.Xcode
Version:         6.1 (6604)
Build Info:      IDEFrameworks-6604000000000000~2
App Item ID:     497799835
App External ID: 752282650
Code Type:       X86-64 (Native)
Parent Process:  launchd [185]
Responsible:     Xcode [7904]
User ID:         501

Date/Time:       2014-11-25 12:32:49.348 -0800
OS Version:      Mac OS X 10.9.5 (13F34)
Report Version:  11
Anonymous UUID:  E22980F9-B80B-F985-200A-FE471C623C56


Crashed Thread:  23  <DBGLLDBSessionThread (pid=7957)>

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000001409bdfd0

VM Regions Near 0x1409bdfd0:
    Stack                  000000014093b000-00000001409bd000 [  520K] rw-/rwx SM=COW  thread 22
--> STACK GUARD            00000001409bd000-00000001409be000 [    4K] ---/rwx SM=NUL  stack guard for thread 23
    Stack                  00000001409be000-0000000140a40000 [  520K] rw-/rwx SM=COW  thread 23

Application Specific Information:
ProductBuildVersion: 6A1052d

...

...

Thread 23 Crashed:: <DBGLLDBSessionThread (pid=7957)>
0   libsystem_pthread.dylib         0x00007fff90eb82cf __mtx_droplock + 17
1   libsystem_pthread.dylib         0x00007fff90eb88f3 pthread_mutex_unlock + 60
2   com.apple.LLDB.framework        0x000000011808f8be lldb_private::Mutex::Locker::~Locker() + 22
3   com.apple.LLDB.framework        0x00000001180ed55f GDBRemoteCommunication::CheckForPacket(unsigned char const*, unsigned long, StringExtractorGDBRemote&) + 2423
4   com.apple.LLDB.framework        0x00000001180ec99e GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock(StringExtractorGDBRemote&, unsigned int) + 88
5   com.apple.LLDB.framework        0x00000001181eeb1b GDBRemoteCommunicationClient::SendPacketAndWaitForResponse(char const*, unsigned long, StringExtractorGDBRemote&, bool) + 91
6   com.apple.LLDB.framework        0x00000001180f7574 ProcessGDBRemote::DoReadMemory(unsigned long long, void*, unsigned long, lldb_private::Error&) + 216
7   com.apple.LLDB.framework        0x00000001181a452a lldb_private::Process::ReadMemoryFromInferior(unsigned long long, void*, unsigned long, lldb_private::Error&) + 94
8   com.apple.LLDB.framework        0x0000000118171889 lldb_private::ProcessStructReader::ProcessStructReader(lldb_private::Process*, unsigned long long, lldb_private::ClangASTType) + 561
9   com.apple.LLDB.framework        0x0000000118169082 lldb_private::SwiftLanguageRuntime::ClassMetadata::ClassMetadata(lldb_private::SwiftLanguageRuntime&, unsigned long long) + 354
10  com.apple.LLDB.framework        0x000000011816625d lldb_private::SwiftLanguageRuntime::GetMetadataForLocation(unsigned long long) + 531
11  com.apple.LLDB.framework        0x00000001181690d1 lldb_private::SwiftLanguageRuntime::ClassMetadata::ClassMetadata(lldb_private::SwiftLanguageRuntime&, unsigned long long) + 433
12  com.apple.LLDB.framework        0x000000011816625d lldb_private::SwiftLanguageRuntime::GetMetadataForLocation(unsigned long long) + 531
13  com.apple.LLDB.framework        0x00000001181690d1 lldb_private::SwiftLanguageRuntime::ClassMetadata::ClassMetadata(lldb_private::SwiftLanguageRuntime&, unsigned long long) + 433
14  com.apple.LLDB.framework        0x000000011816625d lldb_private::SwiftLanguageRuntime::GetMetadataForLocation(unsigned long long) + 531
15  com.apple.LLDB.framework        0x00000001181690d1 lldb_private::SwiftLanguageRuntime::ClassMetadata::ClassMetadata(lldb_private::SwiftLanguageRuntime&, unsigned long long) + 433
16  com.apple.LLDB.framework        0x000000011816625d lldb_private::SwiftLanguageRuntime::GetMetadataForLocation(unsigned long long) + 531
17  com.apple.LLDB.framework        0x00000001181690d1 lldb_private::SwiftLanguageRuntime::ClassMetadata::ClassMetadata(lldb_private::SwiftLanguageRuntime&, unsigned long long) + 433
18  com.apple.LLDB.framework        0x000000011816625d lldb_private::SwiftLanguageRuntime::GetMetadataForLocation(unsigned long long) + 531

...

...

采纳答案by Questor

There have been many solutions proposed over the years for this kind of bizarre XCode behavior, so I have included all those steps as well... however, I have added a few of my own that (when done together and in order) have never failed to resolve every weird XCode issue that I have come across...

多年来，已经针对这种奇怪的 XCode 行为提出了许多解决方案，所以我也包括了所有这些步骤......但是，我添加了一些我自己的（一起并按顺序完成时）从未未能解决我遇到的每一个奇怪的 XCode 问题......

PLEASE NOTE:Doing ALL of these steps (in order) can be CRITICAL... I realize that some of them at first glance seem like overkill or like they should not matter, but my experience has shown that each step plays a part in getting XCode back into proper working order. Therefore, I do NOT recommend skipping any steps or changing their order.

请注意：执行所有这些步骤（按顺序）可能很关键......我意识到其中一些乍一看似乎有点矫枉过正，或者它们应该无关紧要，但我的经验表明，每一步都在获得XCode 恢复正常工作状态。因此，我不建议跳过任何步骤或更改其顺序。

With that said, if you discover the need to tweak the steps below, please do post a comment... XCode does change constantly so these steps may also need change as well over time.

话虽如此，如果您发现需要调整以下步骤，请发表评论... XCode 确实在不断变化，因此这些步骤也可能随着时间的推移而发生变化。

After XCode crashes:

XCode 崩溃后：

1) If simulator is still running make sure to select IOS Simulator->Reset Content And Settings before closing it.

1) 如果模拟器仍在运行，请确保在关闭之前选择 IOS Simulator->重置内容和设置。

2) Close Simulator (CMD-Q)

2）关闭模拟器（CMD-Q）

3) Window --> Organizer --> Delete derived data

3) 窗口 --> 管理器 --> 删除派生数据

4) If debugging on ANY devices, delete the app from the device and REBOOT the device completely.

4) 如果在任何设备上调试，请从设备上删除应用程序并完全重新启动设备。

5) Launch XCode

5) 启动 XCode

6) Remove All breakpoints

6) 删除所有断点

7) Product --> (hold down Alt/option key) Clean Build Folder

7) Product --> (按住 Alt/option 键) Clean Build Folder

8) Product --> Clean

8) 产品 --> 清洁

9) Close XCode again via XCode->Quit XCode (NOTE: Must be a GRACEFULExit, so XCode can properly do a complete shutdown/cleanup cycle)

9）关闭了XCode再次通过XCode->退出的XCode（注：必须是GRACEFUL退出，这样的XCode可以适当做一个完整的关机/清理周期）

10) Reboot your Mac

10) 重启你的 Mac

11) Launch Xcode

11) 启动Xcode

12) If running in simulator, pick a different device to simulate than when it crashed.

12) 如果在模拟器中运行，请选择与崩溃时不同的设备进行模拟。

13) Do a test run of your app (with no breakpoints)

13) 对您的应用程序进行测试运行（没有断点）

14) If all goes well, start adding a breakpoints (All Exceptions is always a good starting point).

14) 如果一切顺利，开始添加断点（All Exceptions 总是一个好的起点）。

HAIL MARY CLAUSE (a.k.a. "The Corbomite Maneuver"): If doing all the above did not work then re-perform all the above steps again, but insert the following step between steps 9 and 10: 9A) Delete XCode app and re-install XCode.

HAIL MARY CLAUSE（又名“The Corbomite Maneuver”）：如果上述所有操作均无效，则再次重新执行上述所有步骤，但在步骤 9 和 10 之间插入以下步骤：9A) 删除 XCode 应用程序并重新安装代码。