xcode 所有异常断点都在模拟器上无故停止

All exception break point is stopping for no reason on simulator

提问by MCMatan

This is very annoying, every time I'm trying to debug on the simulator with "all exception break point", app stops for no reason on this line:

这很烦人，每次我尝试在模拟器上使用“所有异常断点”进行调试时，应用程序都会在这一行无缘无故地停止：

return UIApplicationMain(argc, argv, nil, NSStringFromClass([STAppDelegate class]));

Did any one else found him self struggling with this issue?

有没有其他人发现他在这个问题上挣扎？

Thanks!

谢谢！

EDIT

编辑

Back trace on first throw:

第一次投掷时的回溯：

 thread #1: tid = 0x1d96b, 0x36fbf540 libc++abi.dylib`__cxa_throw, queue = 'com.apple.main-thread', stop reason = breakpoint 3.2
    frame #0: 0x36fbf540 libc++abi.dylib`__cxa_throw
    frame #1: 0x306975cc libFontParser.dylib`TFileDescriptorContext::TFileDescriptorContext(char const*) + 112
    frame #2: 0x306973d8 libFontParser.dylib`TFileDataReference::TFileDataReference(char const*) + 164
    frame #3: 0x306971fc libFontParser.dylib`TFileDataSurrogate::TFileDataSurrogate(char const*, bool) + 188
    frame #4: 0x3069555a libFontParser.dylib`TFont::CreateFontEntitiesForFile(char const*, bool, TSimpleArray<TFont*>&, bool, short, char const*) + 1402
    frame #5: 0x30694a80 libFontParser.dylib`FPFontCreateFontsWithPath + 224
    frame #6: 0x2a5032bc libCGXType.A.dylib`create_private_data_with_path + 12
    frame #7: 0x2a3ca3c4 CoreGraphics`CGFontCreateFontsWithPath + 24
    frame #8: 0x2a4855d6 CoreGraphics`CGFontCreateFontsWithURL + 310
    frame #9: 0x313dfee4 GraphicsServices`AddFontsFromURLOrPath + 68
    frame #10: 0x313e39de GraphicsServices`__Initialize_block_invoke + 934
    frame #11: 0x0121fabe libdispatch.dylib`_dispatch_client_callout + 22
    frame #12: 0x01220750 libdispatch.dylib`dispatch_once_f + 100
    frame #13: 0x313df72c GraphicsServices`Initialize + 196
    frame #14: 0x377944c4 libobjc.A.dylib`_class_initialize + 536
    frame #15: 0x3779a046 libobjc.A.dylib`lookUpImpOrForward + 254
    frame #16: 0x37799f3e libobjc.A.dylib`_class_lookupMethodAndLoadCache3 + 34
    frame #17: 0x377a01f8 libobjc.A.dylib`_objc_msgSend_uncached + 24
    frame #18: 0x2d673b6e UIKit`-[UIStatusBarNewUIForegroundStyleAttributes makeTextFontForStyle:] + 78
    frame #19: 0x2d634d94 UIKit`-[UIStatusBarForegroundStyleAttributes textFontForStyle:] + 104
    frame #20: 0x2d5e767e UIKit`-[UIStatusBarServiceItemView updateForContentType:serviceString:serviceCrossfadeString:maxWidth:actions:] + 390
    frame #21: 0x2d5e74ee UIKit`-[UIStatusBarServiceItemView updateForNewData:actions:] + 186
    frame #22: 0x2d6428d0 UIKit`-[UIStatusBarItemView initWithItem:data:actions:style:] + 324
    frame #23: 0x2d642568 UIKit`-[UIStatusBarLayoutManager _createViewForItem:withData:actions:] + 108
    frame #24: 0x2d5e6f74 UIKit`-[UIStatusBarLayoutManager _prepareEnabledItemType:withEnabledItems:withData:actions:itemAppearing:itemDisappearing:] + 264
    frame #25: 0x2d5e6e22 UIKit`-[UIStatusBarLayoutManager prepareEnabledItems:withData:actions:] + 74
    frame #26: 0x2d5e6c72 UIKit`-[UIStatusBarForegroundView _setStatusBarData:actions:animated:] + 162
    frame #27: 0x2d5e6b96 UIKit`-[UIStatusBarForegroundView setStatusBarData:actions:animated:] + 710
    frame #28: 0x2d671ebe UIKit`__44-[UIStatusBar _prepareToSetStyle:animation:]_block_invoke + 358
    frame #29: 0x2d5fc230 UIKit`+[UIView(Animation) performWithoutAnimation:] + 72
    frame #30: 0x2d66fcf4 UIKit`-[UIStatusBar _prepareToSetStyle:animation:] + 688
    frame #31: 0x2d6579ca UIKit`-[UIStatusBar _requestStyleAttributes:animationParameters:] + 290
    frame #32: 0x2d65696e UIKit`-[UIStatusBar requestStyle:animated:] + 86
    frame #33: 0x2d65559a UIKit`-[UIApplication _createStatusBarWithRequestedStyle:orientation:hidden:] + 406
    frame #34: 0x2d85122a UIKit`-[UIApplication _runWithMainScene:transitionContext:completion:] + 970
    frame #35: 0x2d85bc68 UIKit`__84-[UIApplication _handleApplicationActivationWithScene:transitionContext:completion:]_block_invoke + 36
    frame #36: 0x2d84fc5a UIKit`-[UIApplication workspaceDidEndTransaction:] + 130
    frame #37: 0x3086c0e0 FrontBoardServices`__31-[FBSSerialQueue performAsync:]_block_invoke + 12
    frame #38: 0x2a13782c CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12
    frame #39: 0x2a136af0 CoreFoundation`__CFRunLoopDoBlocks + 216
    frame #40: 0x2a13564a CoreFoundation`__CFRunLoopRun + 1714
    frame #41: 0x2a082db0 CoreFoundation`CFRunLoopRunSpecific + 476
    frame #42: 0x2a082bc2 CoreFoundation`CFRunLoopRunInMode + 106
    frame #43: 0x2d653c36 UIKit`-[UIApplication _run] + 558
    frame #44: 0x2d64ea30 UIKit`UIApplicationMain + 1440
  * frame #45: 0x003b4ec2 Stox`main(argc=1, argv=0x01200b08) + 178 at main.m:17

Third:

第三：

 thread #1: tid = 0x1d96b, 0x36fbf540 libc++abi.dylib`__cxa_throw, queue = 'com.apple.main-thread', stop reason = breakpoint 3.2
    frame #0: 0x36fbf540 libc++abi.dylib`__cxa_throw
    frame #1: 0x30798c22 libTrueTypeScaler.dylib`ScalerNewBlock(memoryContext*, long, long, void*, unsigned char, unsigned char) + 430
    frame #2: 0x3077e172 libTrueTypeScaler.dylib`OutlineToPath(memoryContext*, fnt_ElementType const*) + 178
    frame #3: 0x3079502a libTrueTypeScaler.dylib`ObtainDesiredOutline(memoryContext*, fnt_ElementType const*, unsigned long, void**) + 10
    frame #4: 0x3077e07c libTrueTypeScaler.dylib`RenderPath(fsg_SplineKey*, memoryContext*, scalerGlyph const*) + 36
    frame #5: 0x3077c980 libTrueTypeScaler.dylib`TTRenderGlyphs + 436
    frame #6: 0x306c5722 libFontParser.dylib`TConcreteFontScaler::CopyGlyphPath(unsigned short, CGAffineTransform const*) const + 378
    frame #7: 0x306a0ce6 libFontParser.dylib`FPFontCopyGlyphPath + 494
    frame #8: 0x2a3abb4a CoreGraphics`CGFontCreateGlyphPath + 30
    frame #9: 0x2a3aba56 CoreGraphics`CGFontCreateGlyphBitmap + 266
    frame #10: 0x2a3b3c1a CoreGraphics`CGGlyphBuilder::create_missing_bitmaps(CGGlyphIdentifier const*, unsigned long, CGGlyphBitmap const**) + 82
    frame #11: 0x2a6fd4dc libRIP.A.dylib`render_glyphs + 172
    frame #12: 0x2a6fcaca libRIP.A.dylib`draw_glyph_bitmaps + 906
    frame #13: 0x2a6fc430 libRIP.A.dylib`ripc_DrawGlyphs + 1108
    frame #14: 0x2a3a1002 CoreGraphics`draw_glyphs + 274
    frame #15: 0x2aaae268 CoreText`DrawSbixGlyphsAtPositions(TFont const*, CGFont*, TCFRef<__CFData const*> const&, unsigned short const*, CGPoint const*, unsigned long, CGContext*, CGAffineTransform, CGAffineTransform) + 1880
    frame #16: 0x2aa6bcce CoreText`CTFontDrawGlyphsWithAdvances + 470
    frame #17: 0x349eba1a UIFoundation`__NSStringDrawingEngine + 6710
    frame #18: 0x349efa64 UIFoundation`-[NSAttributedString(NSExtendedStringDrawing) drawWithRect:options:context:] + 532
    frame #19: 0x2d603370 UIKit`-[UILabel _drawTextInRect:baselineCalculationOnly:] + 4440
    frame #20: 0x2d668ed4 UIKit`-[UILabel drawTextInRect:] + 488
    frame #21: 0x2d668ce8 UIKit`-[UILabel drawRect:] + 84
    frame #22: 0x2d668c70 UIKit`-[UIView(CALayerDelegate) drawLayer:inContext:] + 400
    frame #23: 0x2d045910 QuartzCore`-[CALayer drawInContext:] + 228
    frame #24: 0x2d02f350 QuartzCore`CABackingStoreUpdate_ + 2068
    frame #25: 0x2d110b6c QuartzCore`___ZN2CA5Layer8display_Ev_block_invoke + 52
    frame #26: 0x2d02eb34 QuartzCore`x_blame_allocations + 88
    frame #27: 0x2d02e7e4 QuartzCore`CA::Layer::display_() + 1156
    frame #28: 0x2d012d9c QuartzCore`CA::Layer::display_if_needed(CA::Transaction*) + 200
    frame #29: 0x2d012a60 QuartzCore`CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 24
    frame #30: 0x2d012446 QuartzCore`CA::Context::commit_transaction(CA::Transaction*) + 222
    frame #31: 0x2d012250 QuartzCore`CA::Transaction::commit() + 324
    frame #32: 0x2d5e51c8 UIKit`_afterCACommitHandler + 132
    frame #33: 0x2a137844 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 20
    frame #34: 0x2a134f28 CoreFoundation`__CFRunLoopDoObservers + 276
    frame #35: 0x2a13532a CoreFoundation`__CFRunLoopRun + 914
    frame #36: 0x2a082db0 CoreFoundation`CFRunLoopRunSpecific + 476
    frame #37: 0x2a082bc2 CoreFoundation`CFRunLoopRunInMode + 106
    frame #38: 0x313e7050 GraphicsServices`GSEventRunModal + 136
    frame #39: 0x2d64ea30 UIKit`UIApplicationMain + 1440
  * frame #40: 0x003b4ec2 Stox`main(argc=1, argv=0x01200b08) + 178 at main.m:17

回答by nmock

I was just experiencing the same exact problem and tracked down the issue.

我刚刚遇到了同样的问题并找到了问题所在。

Make sure that all fonts that you specify in your Info.plistunder Fonts provided by this applicationare actually in your application bundle.

确保您在Info.plist下面指定的所有字体Fonts provided by this application实际上都在您的应用程序包中。

回答by Sandy Chapman

There's a more accurate way of tracking down the suspect font in your app using the debugger and the fact that it's conveniently stopped at the call.

有一种更准确的方法可以使用调试器来追踪应用中的可疑字体，而且它可以方便地在调用时停止。

Step 1: Reproduce the __cxa_throw breakpoint

第 1 步：重现 __cxa_throw 断点

Usually this happens when instantiating one of (or possibly the first) UIView object in your app. You'll see your debugger has broken and you'll have a stack such as this:

通常在您的应用程序中实例化一个（或可能是第一个） UIView 对象时会发生这种情况。你会看到你的调试器坏了，你会有一个这样的堆栈：

Step 2: Select the entry in the stack trace with the symbol FPFontCreateFontsWithPath

步骤 2：在堆栈跟踪中选择带有符号的条目 FPFontCreateFontsWithPath

In my case, this entry was line 7 in the stack.

就我而言，此条目是堆栈中的第 7 行。

If you take a look at the disassembly, you'll notice the function signature of this entry:

如果你看一下反汇编，你会注意到这个条目的函数签名：

Ah, cool! Looks like it takes some C strings. I betcha one of those is a filepath too!

啊，酷！看起来它需要一些 C 字符串。我敢打赌其中一个也是文件路径！

Step 3: Locate that string in the app memory

第 3 步：在应用程序内存中找到该字符串

I'm running this in a (x86_64) simulator, which on my computer stores the function arguments in some of the registers beginning with r. More details on registers here.

我在 (x86_64) 模拟器中运行它，它在我的计算机上将函数参数存储在一些以r. 有关寄存器的更多详细信息，请访问此处。

Either press Shift+Command+M or select the "Debug > Debug Workflow > View Memory" option from the menu.

按 Shift+Command+M 或从菜单中选择“调试 > 调试工作流 > 查看内存”选项。

At the bottom of this view, go through the registers one by one and enter the addresses. In my case, r14 contained the path of the file.

在此视图的底部，逐个查看寄存器并输入地址。就我而言， r14 包含文件的路径。

Alright, so now I know the font that's messed up. It's looking for HelveticaNeue.ttc. Let's find the reference to that in the project.

好的，现在我知道乱七八糟的字体了。它正在寻找 HelveticaNeue.ttc。让我们在项目中找到对它的引用。

Open a terminal, navigate to your project and run:

打开终端，导航到您的项目并运行：

$ ~/W/X/project> grep -R "HelveticaNeue" ./
.//MyProject/Main.Storyboard:        <array key="HelveticaNeue.ttc">
.//MyProject/Main.Storyboard:            <string>HelveticaNeue</string>
.//MyProject/Main.Storyboard:                                <fontDescription key="fontDescription" name="HelveticaNeue" family="Helvetica Neue" pointSize="18"/>

Awesome, now either switch those to system by replacing name="HelveticaNeue" family="Helvetica Neue"with type="system", open the storyboard and manually edit them or add a reference to the missing font to your app (info.plist and target).

真棒，现在要么通过更换切换那些系统name="HelveticaNeue" family="Helvetica Neue"与type="system"，打开故事板和手动编辑或添加到您的应用程序（的info.plist和目标），以缺少的字体的引用。

Step 4: Celebrate

第 4 步：庆祝

回答by gnasher729

As the backtrace shows, the app didn't stop for no reason. It stopped because an exception was thrown, and it looks like a C++ exception.

正如回溯显示的那样，该应用程序并没有无缘无故地停止。它因为抛出异常而停止，它看起来像一个 C++ 异常。

Unlike Objective-C, where exceptions should only be thrown as the result of programming errors and therefore are very rare, there is a lot of C++ code around that throws and catches lots of exceptions. In that situation, probably best to only set a breakpoint on Objective-C exceptions, not all exceptions.

不像Objective-C，异常应该只作为编程错误的结果抛出，因此非常罕见，有很多C++代码会抛出和捕获很多异常。在那种情况下，最好只在 Objective-C 异常上设置断点，而不是所有异常。

回答by DaNLtR

If you didn't find a problem in .plist file maybe the problem is in your .storyboard file.. Open it as source codefrom Xcode or in textView from Finder - search for <customFonts key="customFonts">I had there some old irrelevant array/font inside...:) just deleted it and it stopped

如果您在 .plist 文件中没有发现问题，那么问题可能出在您的 .storyboard 文件中。从 Xcode 中将其作为源代码打开，或者在 Finder的 textView 中打开- 搜索<customFonts key="customFonts">我在里面有一些旧的不相关数组/字体。 .:) 刚刚删除它并停止

回答by Aleksandr Borshchenko

In my case the reference was inside xcuserdata:

在我的情况下，参考在里面xcuserdata：

user$ grep -R "HelveticaNeue" ./
Binary file .//MyProject.xcworkspace/xcuserdata/user.xcuserdatad/UserInterfaceState.xcuserstate matches

回答by S1LENT WARRIOR

I solved this issue by combining nmock's answerwith DaNLtR's answer.

我通过将nmock 的回答与DaNLtR 的回答结合起来解决了这个问题。

So at first i looked for <customFonts key="customFonts">and there was Montserrat-Lightpresent in it.
But it wasn't neither present in info.plist nor was it added to the project.

所以一开始我在找<customFonts key="customFonts">，里面有Montserrat-Light。
但它既没有出现在 info.plist 中，也没有添加到项目中。

The problem vanished once i bundled Montserrat-Light.ttfinto the project and added an entry for this font under Fonts provided by this applicationin info.plist.

一旦我捆绑Montserrat-Light.ttf到项目中并Fonts provided by this application在info.plist.

So following is the summary of above mentioned solution:

因此，以下是上述解决方案的摘要：

1. Look for your Storyboardor Xibfiles for any Custom Fonts.
   You'll find them in <customFonts key="customFonts">
2. If there is Actuallya Custom Font mentioned, then follow steps 3 and 4
3. Add the font to your Xcode Project.
4. Add an entry to info.plist under Fonts provided by this application.
   This entry should be name of the font file followed by its extension.
5. In case if <customFonts key="customFonts">doesn't contain any Custom Font (e.g: Helvetica-Neue etc), then try deleting the <customFonts key="customFonts">entry in Stroyboardor Xibfile as stated in DaNLtR's answer

1. 查找您的Storyboard或Xib任何自定义字体的文件。
   你会发现他们在<customFonts key="customFonts">
2. 如果实际上提到了自定义字体，则按照步骤 3 和 4
3. 将字体添加到您的 Xcode 项目中。
4. 在 info.plist 下添加一个条目Fonts provided by this application。
   此项应该是字体文件的名称，后跟其扩展名。
5. 如果<customFonts key="customFonts">不包含任何自定义字体（例如：Helvetica-Neue 等），则尝试删除DaNLtR 的回答中所述的<customFonts key="customFonts">条目Stroyboard或Xib文件

I know its very late to answer but hope this helps someone.

我知道现在回答已经很晚了，但希望这对某人有所帮助。

回答by justin

An exception is being thrown, but the caller (e.g. in libFontParser and libTrueTypeScaler) is handling it and it is not reaching your program.

正在抛出异常，但调用方（例如在 libFontParser 和 libTrueTypeScaler 中）正在处理它并且它没有到达您的程序。

Unless you see other evidence of a problem (such as a log message) or the exception reaches your program, assume that the implementation is handling it. You can continue past these instances in the debugger without worry.

除非您看到问题的其他证据（例如日志消息）或异常到达您的程序，否则假设实现正在处理它。您可以在调试器中继续跳过这些实例而无需担心。