Xcode 6.1 和 6.1.1 在调试器断点处崩溃（模拟器）

Posted 2023-02-23

【中文标题】Xcode 6.1 和 6.1.1 在调试器断点处崩溃（模拟器）

【英文标题】：Xcode 6.1 and 6.1.1 Crashes on Debugger Breakpoint (Simulator)

【发布时间】：2015-01-23 22:42:34

【问题描述】：

我和其他许多人一样，遇到过 Xcode 6+ 崩溃的问题。我得到 SourceKit 崩溃以及完整的应用程序崩溃。一时兴起，我想我会尝试 6.1.1（开发人员会员中心），但更糟糕的是，调试器断点现在会导致应用程序完全崩溃。所以我说算了，回到 6.1，但是我在调​​试器断点的时候还是会崩溃。

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

这绝对是疯了！其他人得到这个？

我尝试过的事情：

删除 /Application/Xcode.app/ & ~/Library/Developer/* 清理项目 重新启动我的笔记本电脑 在物理设备上执行的断点（ 杀鸡撒血

堆栈跟踪的头部：

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

...

【问题讨论】：

“杀鸡并把它的血洒满”这确实应该奏效。什么样的鸡？

更认真，请在这里尝试我的回答：***.com/a/6247073/341994 最后的两个编辑特别重要。 Xcode 维护了一些邪恶的缓存，这些缓存可能会变得损坏/陈旧，将它们吹走会有很大帮助。

感谢您的建议。我尝试了所有的清理，但问题仍然存在。我用更多细节更新了我的问题，并且刚刚发现这只发生在模拟器上。物理设备不会使调试器断点崩溃。

你是否删除了所有断点，只设置了一个？当然，你应该提交一个错误。

我撒谎了，它确实会在手机上崩溃。这是一个非常具体的断点，它同时使 xcode 6.1 和 6.1.1 崩溃。啊啊啊啊啊！！！

【参考方案1】：

多年来针对这种奇怪的 Xcode 行为提出了许多解决方案，因此我也包含了所有这些步骤；但是，我添加了一些我自己的（当一起并按顺序完成时）从来没有解决我遇到的每一个奇怪的 Xcode 问题。

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

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

Xcode 崩溃后：

如果模拟器仍在运行，请确保在关闭之前选择 ios Simulator->Reset Content And Settings。

关闭模拟器(CMD-Q)

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

如果在任何设备上调试，请从设备中删除应用并完全重启设备。

启动 Xcode

删除所有断点

Product ->（按住Alt/option键）清理构建文件夹

产品 -> 清洁

通过 Xcode->Quit Xcode 再次关闭 Xcode（注意：必须是 GRACEFUL 退出，这样 Xcode 才能正确执行完整的关闭/清理周期）

重启你的 Mac

启动 Xcode

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

测试你的应用程序（没有断点）

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

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

【讨论】：

我做了所有这些，但感谢您比我更完整地记录它。看起来即使做了上面列出的所有事情，最终它还是会再次崩溃。 悲伤的脸 有一个6.2的作品，也许会带来更多的稳定性。

以上真的是为了修复XCode进入不良状态。但是，错误状态的原因可能与您正在运行的代码有关……例如，对控制台进行大量日志记录将不可避免地导致 XCode 开始崩溃。此外，C/C++（甚至 objC）中的错误内存指针会使任何环境随着时间的推移变得有点不稳定（即使被捕获）。重点是上述内容旨在让 XCode 恢复正常......此时我将尝试缩小您尝试运行的项目中问题的原因。也就是说，您仍然需要修复 XCode 保持稳定的根本原因。

好点！我也发现了。清理整个事情有时可以帮助找到崩溃的根本原因。感谢您的澄清。

我很怀疑，但它确实对我有用，在 6.4 中将断点放入回调的回调中时发生崩溃 :)