是“EXC_BREAKPOINT（SIGTRAP）”调试断点引起的异常？ [英] Are "EXC_BREAKPOINT (SIGTRAP)" exceptions caused by debugging breakpoints?
问题描述
我有一个多线程的应用程序，在我所有的测试机器上非常稳定，似乎几乎每个我的用户都稳定（基于没有投诉的崩溃）。应用程序崩溃频繁的一个用户，虽然，谁是足够发送崩溃报告。所有崩溃报告（约10个连续报告）看起来基本相同：
日期/时间：2010-04-06 11:44 ：56.106 -0700
操作系统版本：Mac OS X 10.6.3（10D573）
报告版本：6
异常类型：EXC_BREAKPOINT（SIGTRAP）
异常代码： 0x0000000000000002，0x0000000000000000
崩溃的线程：0调度队列：com.apple.main线程
线程0崩溃：调度队列：com.apple.main线程
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（*） 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 。但是，该应用程序绝对是使用发布作为活动构建配置。我假设使用释放配置阻止任何断点的设置 - 但是我不知道确切的方式如何断点工作，或者程序是否需要从gdb中为断点运行有任何效果。
我的问题是：我的离开断点设置是否是用户观察到的崩溃的原因？如果是这样，为什么断点只对这一个用户造成问题？如果没有，有其他人有类似的问题[NSFont fontWithName：size：]？
我可能只是尝试删除断点并发送回给用户，我不知道我有多少钱留给那个用户。我想更通常地理解是否保留断点设置可能会导致一个问题（当应用程序是使用释放配置构建时）。
是否因调试断点而导致EXC_BREAKPOINT（SIGTRAP）异常？
没有。其他方法，实际上：SIGTRAP（跟踪陷阱）将导致调试器打破（中断）您的程序，与实际断点相同的方式。但这是因为调试器总是在崩溃时崩溃，并且SIGTRAP（像其他几个信号）是一种类型的崩溃。
SIGTRAPs通常是由NSExceptions抛出引起的，甚至可以直接提高
我现在注意到我忘记删除一些调试断点，包括_NSLockError，[NSException raise]和objc_exception_throw。
这些不是断点。其中两个是函数， - [NSException raise] 是一个方法。
我假设使用发布配置阻止设置任何断点， -
否。
配置为 build 配置。它们影响Xcode如何构建您的应用程序。
断点不是构建的一部分;你在调试器中设置它们。
由于它们不是构建的一部分，因此它不可能
我不知道断点是如何工作的...
当程序跳到断点时，调试器会中断（中断）程序，然后你可以检查程序的状态并小心前进，程序错误。
由于是停止程序的调试器，当你不在调试器下运行程序时，断点不起作用。
...或者程序是否需要在gdb中运行以获得断点。
它。调试器断点只能在调试器中工作。
我的问题是：我可以将断点设置为
<$ p $ b首先，如上所述，即使这些断点不知何故被转移到用户的系统，断点只在调试器中有效。如果程序没有在调试器下运行，调试器不能在断点上停止。用户几乎肯定不是在调试器下运行你的应用程序，特别是因为他们有一个崩溃注销。
即使他们在调试器下运行你的应用程序所有这些断点设置，断点只有当你的程序到达这一点，所以其中一个断点只能触发，如果你或Cocoa调用
_NSLockError，- [NSException raise]或objc_exception_throw。达到这一点不会是问题的根源，它会是问题的症状。
如果你确实崩溃作为一个结果那些被调用的，你的崩溃日志将至少有一个在其中命名。它不是。
所以，这不是你的断点（不同的机器，调试器不涉及），它不是一个Cocoa异常 - 提到，Cocoa异常是SIGTRAP的一个原因，但它们不是唯一的。
如果没有，是否有其他人在[NSFont fontWithName：size：]有类似的问题？
我们无法判断我们所遇到的任何问题是否类似，因为您切断了崩溃日志。我们什么也不知道崩溃发生在什么上下文。
唯一的好东西是二进制图像部分，因为我们没有你的dSYM bundles，这意味着我们不能使用该部分来表示崩溃日志。
另一方面，你可以。为此，我写了一个应用;将崩溃日志馈送到它，它应该自动检测dSYM软件包（您为分发的每个发行版本保留dSYM软件包，对吧？），并将您的函数和方法名称还原到堆栈跟踪，无论您的函数和方法出现在哪里。
有关详细信息，请参阅 Xcode调试指南。
I have a multithreaded app that is very stable on all my test machines and seems to be stable for almost every one of my users (based on no complaints of crashes). The app crashes frequently for one user, though, who was kind enough to send crash reports. All the crash reports (~10 consecutive reports) look essentially identical:
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(....more text follows)
First, I spent a long time investigating [NSFont fontWithName:size:]. I figured that maybe the user's fonts were screwed up somehow, so that [NSFont fontWithName:size:] was requesting something non-existent and failing for that reason. I added a bunch of code using [[NSFontManager sharedFontManager] availableFontNamesWithTraits:NSItalicFontMask] to check for font availability in advance. Sadly, these changes didn't fix the problem.
I've now noticed that I forgot to remove some debugging breakpoints, including _NSLockError, [NSException raise], and objc_exception_throw. However, the app was definitely built using "Release" as the active build configuration. I assume that using the "Release" configuration prevents setting of any breakpoints--but then again 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? If so, why would the breakpoints cause a problem only for this one user? If not, has anybody else had similar problems with [NSFont fontWithName:size:]?
I will probably just try removing the breakpoints and sending back to the user, but I'm not sure how much currency I have left with that user. And I'd like to understand more generally whether leaving the breakpoints set could possibly cause a problem (when the app is built using "Release" configuration).
解决方案Are "EXC_BREAKPOINT (SIGTRAP)" exceptions caused by debugging breakpoints?
No. Other way around, actually: A SIGTRAP (trace trap) will cause the debugger to break (interrupt) your program, the same way an actual breakpoint would. But that's because the debugger always breaks on a crash, and a SIGTRAP (like several other signals) is one type of crash.
SIGTRAPs are generally caused by NSExceptions being thrown, but not always—it's even possible to directly raise one yourself.
I've now noticed that I forgot to remove some debugging breakpoints, including _NSLockError, [NSException raise], and objc_exception_throw.
Those are not breakpoints. Two of them are functions and
-[NSException raise]is a method.Did you mean you set breakpoints on those functions and that method?
I assume that using the "Release" configuration prevents setting of any breakpoints--
No.
The configurations are build configurations. They affect how Xcode builds your applications.
Breakpoints are not part of the build; you set them in the debugger. They only exist, only get hit, and only stop your program when you run your program under the debugger.
Since they aren't part of the build, it's not possible to pass your breakpoints to a user simply by giving them the app bundle.
I am not sure exactly how breakpoints work …
When your program hits the breakpoint, the debugger breaks (interrupts) your program, whereupon you can examine the program's state and step carefully forward to see how the program goes wrong.
Since it's the debugger that stops your program, breakpoints have no effect when you're not running your program under the debugger.
… or whether the program needs to be run from within gdb for breakpoints to have any effect.
It does. Debugger breakpoints only work within the debugger.
My questions are: could my having left the breakpoints set be the cause of the crashes observed by the user?
No.
First, as noted, even if these breakpoints did somehow get carried over to the user's system, breakpoints are only effective in the debugger. The debugger can't stop on a breakpoint if your program isn't running under the debugger. The user almost certainly isn't running your app under the debugger, especially since they got a crash log out of it.
Even if they did run your app under the debugger with all of these breakpoints set, a breakpoint is only hit when your program reaches that point, so one of these breakpoints could only fire if you or Cocoa called
_NSLockError,-[NSException raise], orobjc_exception_throw. Getting to that point wouldn't be the cause of the problem, it'd be a symptom of the problem.And if you did crash as a result of one of those being called, your crash log would have at least one of them named in it. It doesn't.
So, this wasn't related to your breakpoints (different machine, debugger not involved), and it wasn't a Cocoa exception—as I mentioned, Cocoa exceptions are one cause of SIGTRAPs, but they are not the only one. You encountered a different one.
If not, has anybody else had similar problems with [NSFont fontWithName:size:]?
There's no way we can tell whether any problems we've had are similar because you cut off the crash log. We know nothing about what context the crash happened in.
The only thing that's good to cut out is the "Binary images" section, since we don't have your dSYM bundles, which means we can't use that section to symbolicate the crash log.
You, on the other hand, can. I wrote an app for this purpose; feed the crash log to it, and it should detect the dSYM bundle automatically (you are keeping the dSYM bundle for every Release build you distribute, right?) and restore your function and method names into the stack trace wherever your functions and methods appear.
For further information, see the Xcode Debugging Guide.
这篇关于是“EXC_BREAKPOINT（SIGTRAP）”调试断点引起的异常？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
