“ EXC_BREAKPOINT（SIGTRAP）”异常是否由调试断点引起？

我有一个多线程应用程序，该程序在所有测试机上都非常稳定，并且几乎对我的每个用户都是稳定的（基于对崩溃的抱怨）。不过，该应用程序经常会崩溃，因为一位用户足够发送崩溃报告。所有崩溃报告（约10个连续报告）看起来基本相同：

Date/Time:       2010-04-06 11:44:56.106 -0700
OS Version:      Mac OS X 10.6.3 (10D573)
Report Version:  6

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   com.apple.CoreFoundation        0x90ab98d4 __CFBasicHashRehash + 3348
1   com.apple.CoreFoundation        0x90adf610 CFBasicHashRemoveValue + 1264
2   com.apple.CoreText              0x94e0069c TCFMutableSet::Intersect(__CFSet const*) const + 126
3   com.apple.CoreText              0x94dfe465 TDescriptorSource::CopyMandatoryMatchableRequest(__CFDictionary const*, __CFSet const*) + 115
4   com.apple.CoreText              0x94dfdda6 TDescriptorSource::CopyDescriptorsForRequest(__CFDictionary const*, __CFSet const*, long (*)(void const*, void const*, void*), void*, unsigned long) const + 40
5   com.apple.CoreText              0x94e00377 TDescriptor::CreateMatchingDescriptors(__CFSet const*, unsigned long) const + 135
6   com.apple.AppKit                0x961f5952 __NSFontFactoryWithName + 904
7   com.apple.AppKit                0x961f54f0 +[NSFont fontWithName:size:] + 39

（...更多内容如下）

首先，我花了很长时间研究[NSFont fontWithName：size：]。我发现也许用户的字体以某种方式被弄乱了，所以[NSFont fontWithName：size：]正在请求一些不存在的内容，并且由于该原因而失败。我使用[[NSFontManager sharedFontManager] availableFontNamesWithTraits：NSItalicFontMask]添加了一堆代码来预先检查字体可用性。可悲的是，这些更改并不能解决问题。

现在，我注意到我忘记删除一些调试断点，包括_NSLockError，[NSException提高]和objc_exception_throw。但是，该应用程序肯定是使用“发布”作为活动的构建配置来构建的。我假设使用“发布”配置可以防止设置任何断点-但是，我再次不确定断点是如何工作的，或者不确定是否需要从gdb中运行程序才能使断点生效。

我的问题是：我离开断点设置是否会导致用户观察到崩溃的原因？如果是这样，为什么断点仅对这个用户造成问题？如果不是，[NSFont fontWithName：size：]是否还有其他人遇到类似的问题？

我可能会尝试删除断点并发送回该用户，但是我不确定该用户剩下多少货币。而且，我想更广泛地了解设置断点是否可能导致问题（使用“发布”配置构建应用程序时）。

“ EXC_BREAKPOINT（SIGTRAP）”异常是否由调试断点引起？

否。实际上，还有其他方法：SIGTRAP（跟踪陷阱）将导致调试器中断（中断）您的程序，就像实际断点一样。但这是因为调试器总是在崩溃时中断，而SIGTRAP（就像其他几个信号一样）是崩溃的一种类型。

SIGTRAP通常是由引发NSExceptions引起的，但并非总是如此-甚至有可能直接自己引发。

现在，我注意到我忘记删除一些调试断点，包括_NSLockError，[NSException提高]和objc_exception_throw。

这些不是断点。其中两个是函数，-[NSException raise]是一种方法。

您是说要在这些函数和方法上设置断点吗？

我假设使用“发布”配置可以防止设置任何断点-

没有。

这些配置是构建配置。它们影响Xcode构建应用程序的方式。

断点不是构建的一部分；您在调试器中设置它们。它们仅存在，只会被命中，并且只有在调试器下运行程序时才停止程序。

由于它们不是构建的一部分，因此不可能仅通过向他们提供应用程序捆绑包就将断点传递给用户。

我不确定断点是如何工作的……

当您的程序到达断点时，调试器将中断（中断）您的程序，随后您可以检查程序的状态并仔细向前查看程序如何出错。

因为是调试器停止了程序，所以当您不在调试器下运行程序时，断点不起作用。

…或者是否需要从gdb内部运行程序才能使断点生效。

是的 调试器断点仅在调试器中起作用。

我的问题是：我离开断点设置是否会导致用户观察到崩溃的原因？

没有。

首先，如前所述，即使这些断点确实以某种方式传递到用户的系统中，这些断点也仅在调试器中有效。如果您的程序不在调试器下运行，则调试器无法在断点处停止。用户几乎可以肯定不在调试器下运行您的应用程序，尤其是因为他们从崩溃日志中注销了该应用程序。

即使他们与所有这些断点设置的调试器下运行你的应用程序，当你的程序到这一点，这些断点所以人们只能火灾，如果你或可可称为断点只打了_NSLockError，-[NSException raise]或objc_exception_throw。达到这一点并不是问题的原因，而是问题的征兆。

而且，如果由于其中之一被调用而导致崩溃，那么崩溃日志中将至少有其中一个被命名。没有。

因此，这与您的断点无关（不涉及其他机器，调试器），也不是Cocoa异常-正如我提到的那样，Cocoa异常是SIGTRAP的原因之一，但并非唯一原因。您遇到了另一个。

如果不是，[NSFont fontWithName：size：]是否还有其他人遇到类似的问题？

因为您切断了崩溃日志，所以我们无法判断我们遇到的任何问题是否相似。我们对崩溃发生的背景一无所知。

最好删除的是“二进制图像”部分，因为我们没有您的dSYM软件包，这意味着我们不能使用该部分来表示崩溃日志。

另一方面，您可以。我为此目的编写了一个应用程序；将崩溃日志提供给它，它应该自动检测dSYM软件包（您为分发的每个Release版本保留dSYM软件包，对吗？），然后将函数和方法名称还原到堆栈跟踪中，无论函数和方法出现在何处。

有关更多信息，请参见《Xcode调试指南》。

此用户极有可能安装了损坏的字体。堆栈跟踪绝对支持该假设，事实上它仅影响一个用户。

在这种情况下，除了让用户删除有问题的字体外，您无能为力，因为崩溃发生在Apple代码的深处。

尝试让用户在“字体书”中运行字体验证。为此，请启动“字体书”，在源列表中单击“所有字体”，然后选择所有列出的字体。然后，您可以从“文件”菜单中选择“验证字体” 。

断点不会写入二进制文件。这个人安装的OS坏了，这很不错。检查控制台日志中的dyld消息。

我有同样的错误。出于无法解释的原因，断点是引发EXC_BREAKPOINT异常的原因。解决的办法是删除断点，然后使代码工作。

EXC_BREAKPOINT是调试器使用的一种异常。在代码中设置断点时，编译器会在可执行代码中插入此类型的异常。当执行到达该点时，将引发异常，调试器将其捕获。然后，调试器在“断点”行中显示您的代码。这就是调试器的工作方式。但是在这种情况下，调试器无法正确处理异常，并显示为常规异常错误。

我一生中两次发现此错误：

• 一个大约一年前使用Xcode的人。
• 另一个大约在15年前使用Visual C ++。