Den*_*nis 79 macos cocoa gdb breakpoints exception
我有一个多线程的应用程序,在我的所有测试机器上都非常稳定,并且对于几乎每个用户来说似乎都很稳定(基于没有崩溃的抱怨).该应用程序经常为一个用户崩溃,他们很友好地发送崩溃报告.所有崩溃报告(~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
Run Code Online (Sandbox Code Playgroud)
(....更多文字如下)
首先,我花了很长时间调查[NSFont fontWithName:size:].我想,也许用户的字体被搞砸了,所以[NSFont fontWithName:size:]正在请求一些不存在的东西并因此失败.我使用[[NSFontManager sharedFontManager] availableFontNamesWithTraits:NSItalicFontMask]添加了一堆代码,以提前检查字体可用性.可悲的是,这些变化并没有解决问题.
我现在已经注意到我忘记删除一些调试断点,包括_NSLockError,[NSException raise]和objc_exception_throw.但是,应用程序绝对是使用"Release"作为活动构建配置构建的.我假设使用"Release"配置可以防止设置任何断点 - 但是我再次确定断点是如何工作的,或者是否需要从gdb中为断点运行程序才能产生任何影响.
我的问题是:我的离开断点是否可以成为用户观察到的崩溃的原因?如果是这样,为什么断点只会导致这个用户出现问题?如果没有,还有其他人与[NSFont fontWithName:size:]有类似的问题吗?
我可能只是尝试删除断点并发回给用户,但我不确定我用该用户留下了多少货币.我想更一般地理解是否设置断点可能会导致问题(当使用"Release"配置构建应用程序时).
Pet*_*sey 183
调试断点是否导致"EXC_BREAKPOINT(SIGTRAP)"异常?
实际上,其他方式:SIGTRAP(跟踪陷阱)将导致调试器中断(中断)程序,与实际断点相同.但那是因为调试器总是在崩溃时中断,而SIGTRAP(就像其他几个信号一样)是一种崩溃.
SIGTRAP通常是由抛出NSExceptions引起的,但并非总是如此 - 甚至可以自己直接引发它.
我现在已经注意到我忘记删除一些调试断点,包括_NSLockError,[NSException raise]和objc_exception_throw.
那些不是断点.其中两个是功能,-[NSException raise]是一种方法.
你的意思是你在那些函数和那个方法上设置断点?
我假设使用"Release"配置可以防止设置任何断点 -
没有.
配置是构建配置.它们会影响Xcode构建应用程序的方式.
断点不是构建的一部分; 你在调试器中设置它们.它们只存在,只会被命中,只有在调试器下运行程序时才会停止程序.
由于它们不是构建的一部分,因此无法通过向应用程序包提供断点将其传递给用户.
我不确定断点是如何工作的......
当程序到达断点时,调试器会中断(中断)程序,然后您可以检查程序的状态并仔细检查程序是否出错.
由于调试器是停止程序的,因此当您未在调试器下运行程序时,断点无效.
...或者是否需要在gdb内运行程序以使断点产生任何影响.
确实如此.调试器断点仅在调试器中工作.
我的问题是:我的离开断点是否可以成为用户观察到的崩溃的原因?
没有.
首先,如上所述,即使这些断点以某种方式转移到用户的系统,断点也仅在调试器中有效.如果您的程序未在调试器下运行,则调试器无法在断点处停止.用户几乎肯定没有在调试器下运行你的应用程序,特别是因为他们有一个崩溃日志.
即使他们确实在设置了所有这些断点的调试器下运行您的应用程序,只有当您的程序到达该点时才会触发断点,因此只有当您或Cocoa调用时_NSLockError,才会触发其中一个断点-[NSException raise],或objc_exception_throw.达到这一点不会是问题的原因,它会成为问题的症状.
如果由于其中一个被调用而导致崩溃,那么崩溃日志中至少会有一个以其命名.它没有.
所以,这与您的断点无关(不同的机器,调试器没有涉及),并且它不是Cocoa异常 - 正如我所提到的,Cocoa异常是SIGTRAP的一个原因,但它们不是唯一的.你遇到了另一个.
如果没有,还有其他人与[NSFont fontWithName:size:]有类似的问题吗?
我们无法判断我们遇到的任何问题是否相似,因为您切断了崩溃日志.我们对崩溃发生的背景一无所知.
唯一可以删除的是"二进制图像"部分,因为我们没有你的dSYM包,这意味着我们不能使用该部分来表示崩溃日志.
另一方面,你可以.我为此写了一个应用程序 ; 将崩溃日志提供给它,它应该自动检测dSYM包(你为每个Release发布版本保留dSYM包,对吗?)并将函数和方法名称恢复到堆栈跟踪中,无论你的函数和方法出现在哪里.
有关详细信息,请参阅Xcode调试指南.
该用户极有可能安装了损坏的字体.堆栈跟踪肯定支持该假设,因为它只影响一个用户.
在这种情况下,除了让用户删除有问题的字体之外,你无能为力,因为发生的崩溃发生在Apple的代码深处.
尝试让用户在Font Book中运行字体验证.为此,请启动"字体簿",单击源列表中的" 所有字体 ",然后选择所有列出的字体.然后,您可以从" 文件"菜单中选择" 验证字体 " .