是“EXC_BREAKPOINT (SIGTRAP)"吗?调试断点导致的异常? [英] Are "EXC_BREAKPOINT (SIGTRAP)" exceptions caused by debugging breakpoints?

问题描述

我有一个多线程应用程序，它在我的所有测试机器上都非常稳定，并且对于我的几乎每个用户来说似乎都是稳定的(基于没有崩溃的投诉).但是，该应用程序经常为一位用户崩溃，该用户非常好心地发送崩溃报告.所有崩溃报告(约 10 个连续报告)看起来基本相同:

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)

首先，我花了很长时间研究 [NSFont fontWithName:size:].我想也许用户的字体以某种方式搞砸了，所以 [NSFont fontWithName:size:] 请求的东西不存在并且因此失败.我使用 [[NSFontManager sharedFontManager] availableFontNamesWithTraits:NSItalicFontMask] 添加了一堆代码来提前检查字体的可用性.遗憾的是，这些更改并没有解决问题.

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.

我现在注意到我忘记删除一些调试断点，包括 _NSLockError、[NSException raise] 和 objc_exception_throw.但是，该应用程序肯定是使用发布"作为活动构建配置构建的.我假设使用Release"配置可以防止设置任何断点——但我又不确定断点是如何工作的，或者是否需要从 gdb 中运行程序才能使断点产生任何影响.

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.

我的问题是:我设置的断点是否会导致用户观察到崩溃?如果是这样，为什么断点只会对这个用户造成问题?如果没有，还有其他人对 [NSFont fontWithName:size:] 有类似的问题吗?

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).

推荐答案

EXC_BREAKPOINT (SIGTRAP)"异常是调试断点引起的吗?

Are "EXC_BREAKPOINT (SIGTRAP)" exceptions caused by debugging breakpoints?

没有.反过来，实际上:SIGTRAP(跟踪陷阱)将导致调试器中断(中断)您的程序，就像实际断点一样.但那是因为调试器总是在崩溃和 SIGTRAP(像其他几个 signals) 是一种崩溃类型.

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.

SIGTRAP 通常是由抛出 NSExceptions 引起的，但并非总是如此——甚至可以直接 自己养一个.

SIGTRAPs are generally caused by NSExceptions being thrown, but not always—it's even possible to directly raise one yourself.

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

I've now noticed that I forgot to remove some debugging breakpoints, including _NSLockError, [NSException raise], and objc_exception_throw.

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

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?

我假设使用Release"配置可以防止设置任何断点--

I assume that using the "Release" configuration prevents setting of any breakpoints--

没有

配置是 build 配置.它们会影响 Xcode 构建应用程序的方式.

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.

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

… 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?

没有

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

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.

即使他们确实在设置了所有这些断点的调试器下运行了您的应用程序，也只有在您的程序到达该点时才会触发断点，因此这些断点之一只能在您或 Cocoa 调用 _NSLockError<时触发/code>、-[NSException raise] 或 objc_exception_throw.到达那一点不会是问题的原因，而是问题的症状.

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], or objc_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.

因此，这与您的断点无关(不同的机器，不涉及调试器)，也不是 Cocoa 异常——正如我所提到的，Cocoa 异常是 SIGTRAP 的原因之一，但它们不是唯一的.你遇到了一个不同的人.

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.

如果没有，还有其他人对 [NSFont fontWithName:size:] 有类似的问题吗?

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.

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

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.

另一方面，你可以.为此，我编写了 一个应用程序；将崩溃日志提供给它，它应该会自动检测 dSYM 包(您会为您分发的每个 Release 版本保留 dSYM 包，对吗?)并将您的函数和方法名称恢复到堆栈跟踪中，无论您的函数和方法出现在哪里.

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.

有关详细信息，请参阅 Xcode 调试指南.

For further information, see the Xcode Debugging Guide.

这篇关于是“EXC_BREAKPOINT (SIGTRAP)"吗?调试断点导致的异常?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！