我有一个多线程应用程序，它在我的所有测试机器上都非常稳定，并且对于我的几乎每一位用户来说似乎都是稳定的(基于没有崩溃投诉)。不过，对于一位好心的用户来说，该应用程序经常崩溃，他发送了崩溃报告。所有崩溃报告(约 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 raise] 和 objc_exception_throw。但是，该应用程序肯定是使用“Release”作为事件构建配置来构建的。我假设使用“Release”配置可以防止设置任何断点 - 但话又说回来，我不确定断点到底是如何工作的，或者程序是否需要从 gdb 内运行才能使断点产生任何效果。
我的问题是:我离开断点设置是否会导致用户观察到的崩溃？如果是这样，为什么断点只会对这个用户造成问题？如果没有，其他人是否也遇到过类似的问题 [NSFont fontWithName:size:]？
我可能只是尝试删除断点并将其发送回用户，但我不确定我还给该用户留下了多少货币。我想更广泛地了解保留断点设置是否可能会导致问题(当使用“发布”配置构建应用程序时)。
最佳答案
Are “EXC_BREAKPOINT (SIGTRAP)” exceptions caused by debugging breakpoints?
没有。实际上，反过来说:SIGTRAP(跟踪陷阱)将导致调试器中断(中断)您的程序，就像实际断点一样。但这是因为调试器总是在崩溃时中断，而 SIGTRAP(与其他几个 signals 一样)是一种崩溃类型。
SIGTRAP 通常是由抛出 NSException 引起的，但并非总是如此 - 甚至可以直接 raise一个你自己。
I've now noticed that I forgot to remove some debugging breakpoints, including _NSLockError, [NSException raise], and objc_exception_throw.
那些不是断点。其中两个是函数，-[NSException raise] 是一个方法。
您的意思是在这些函数和方法上设置断点吗？
I assume that using the "Release" configuration prevents setting of any breakpoints--
没有。
这些配置是构建配置。它们影响 Xcode 构建应用程序的方式。
断点不是构建的一部分；您在调试器中设置它们。它们仅存在，仅被命中，并且仅当您在调试器下运行程序时停止您的程序。
由于它们不是构建的一部分，因此无法仅通过向用户提供应用程序包来将断点传递给用户。
I am not sure exactly how breakpoints work …
当您的程序到达断点时，调试器会中断(中断)您的程序，此时您可以检查程序的状态并仔细向前查看程序如何出错。
由于调试器会停止程序，因此当您不在调试器下运行程序时，断点不起作用。
… or whether the program needs to be run from within gdb for breakpoints to have any effect.
确实如此。调试器断点仅在调试器内有效。
My questions are: could my having left the breakpoints set be the cause of the crashes observed by the user?
没有。
首先，如上所述，即使这些断点确实以某种方式转移到用户的系统中，断点也仅在调试器中有效。如果您的程序未在调试器下运行，则调试器无法在断点处停止。用户几乎肯定没有在调试器下运行您的应用程序，特别是因为他们从中获得了崩溃日志。
即使他们确实在设置了所有这些断点的调试器下运行您的应用程序，只有当您的程序到达该点时才会触发断点，因此只有当您或 Cocoa 调用 _NSLockError< 时，这些断点之一才会触发、-[NSException raise] 或 objc_exception_throw。达到这一点并不是问题的原因，而是问题的症状。
如果您确实因其中一个被调用而崩溃，那么您的崩溃日志中将至少有其中一个被命名。事实并非如此。
所以，这与你的断点无关(不同的机器，不涉及调试器)，并且它不是 Cocoa 异常 - 正如我提到的，Cocoa 异常是 SIGTRAP 的原因之一，但它们不是唯一的原因。您遇到了不同的人。
If not, has anybody else had similar problems with [NSFont fontWithName:size:]?
我们无法判断我们遇到的问题是否相似，因为您切断了崩溃日志。我们对事故发生的背景一无所知。
唯一需要删除的是“二进制图像”部分，因为我们没有您的 dSYM 包，这意味着我们无法使用该部分来表示崩溃日志。
另一方面，你可以。我写了an app以此目的;将崩溃日志提供给它，它应该自动检测 dSYM 包(您为您分发的每个版本构建保留 dSYM 包，对吗？)并将函数和方法名称恢复到堆栈跟踪中，无论您的函数和方法出现在哪里。
有关更多信息，请参阅 Xcode Debugging Guide .
关于cocoa - "EXC_BREAKPOINT (SIGTRAP)"异常是否是调试断点导致的？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2611607/