RESOLVED DUPLICATE of bug 22454 21467
Hard crash using @font-face w/ src: url(...) 
https://bugs.webkit.org/show_bug.cgi?id=21467
Summary Hard crash using @font-face w/ src: url(...)
John Engelhart
Reported 2008-10-08 04:17:13 PDT
Ran in to a bug where the browser crashes when using @font-face and src: url(...). It seems to be semi-race condition like. However, the attached tarball seems to reproduce the bug pretty reliably. While I've seen it occasionally crash when using the 'downloaded' @font-face fonts for screen rendering purposes, the attached example only uses the the downloaded fonts for printing purposes (@media print {}). So, to get the browser to crash, you need to try and print the document. This seems to reliably tickle the bug. Its not related to printing, though, it's just a good way to tickle it. Will attach a stack trace later of where it crashes. By a zero order approximation, the back trace always seemed to be the same, whether using the fonts on the screen or printer. Here's the top few frames: Thread 0 Crashed: 0 ??? 0000000000 0 + 0 1 com.apple.WebCore 0x014f55f8 WebCore::SegmentedFontData::isLoading() const + 88 2 com.apple.WebCore 0x01042938 WebCore::FontFallbackList::fontDataAt(WebCore::Font const*, unsigned int) const + 248 3 com.apple.WebCore 0x01037304 WebCore::Font::cachePrimaryFont() const + 36 4 com.apple.WebCore 0x01037b4c WebCore::Font::xHeight() const + 44 The 'isLoading' is probably why it's seems to have semi-race condition like behavior. Some times it works fine, most of the times it doesn't. I wasn't able to distill the .html down in to a compact example, so I've included the full (300K) .html file that I discovered the problem with. Again, I think it has to do with the large amount of 'stuff' at 300K that causes the bug to manifest. Also, right near the <body> start tag, there's a commented out block of 'weird looking' stuff. I found that if you 'force' the resolution of the @font-face fonts right at the start, it caused the problem to go away. So that block of HTML iterates over the normal, italic, bold, italic+bold combinations and uses a zero-width space as the body of text. The attached example is fairly large as it includes the 'full' version of the .html document I'm working on and eight font files (2 font families, 4 styles each).
Attachments
Tarball with .html + fonts that reproduces the bug (210.99 KB, application/octet-stream)
2008-10-08 04:24 PDT, John Engelhart 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
John Engelhart
Comment 1 2008-10-08 04:21:19 PDT
Oh, btw, I'm running Version 4.0 (5528.1, r37300) on PPC 10.5.5. Problem also exists on the latest Safari 4 developer preview. Relevant bits from the crash log backtrace. Process: Safari [33112] Path: /Users/johne/rkl/WebKit.app/Contents/MacOS/WebKit Identifier: org.webkit.nightly.WebKit Version: r37300 (37300) Code Type: PPC (Native) Parent Process: launchd [138] Date/Time: 2008-10-08 06:00:36.821 -0400 OS Version: Mac OS X 10.5.5 (9F33) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000 Crashed Thread: 0 Thread 0 Crashed: 0 ??? 0000000000 0 + 0 1 com.apple.WebCore 0x014f55f8 WebCore::SegmentedFontData::isLoading() const + 88 2 com.apple.WebCore 0x01042938 WebCore::FontFallbackList::fontDataAt(WebCore::Font const*, unsigned int) const + 248 3 com.apple.WebCore 0x01037304 WebCore::Font::cachePrimaryFont() const + 36 4 com.apple.WebCore 0x01037b4c WebCore::Font::xHeight() const + 44 5 com.apple.WebCore 0x00e87384 WebCore::CSSPrimitiveValue::computeLengthDouble(WebCore::RenderStyle*, double, bool) + 196 6 com.apple.WebCore 0x00e87700 WebCore::CSSPrimitiveValue::computeLengthInt(WebCore::RenderStyle*, double) + 32 7 com.apple.WebCore 0x00eb2360 WebCore::CSSStyleSelector::applyProperty(int, WebCore::CSSValue*) + 98112 8 com.apple.WebCore 0x00eb2f38 WebCore::CSSStyleSelector::applyDeclarations(bool, bool, int, int) + 264 9 com.apple.WebCore 0x00eb4c4c WebCore::CSSStyleSelector::styleForElement(WebCore::Element*, WebCore::RenderStyle*, bool, bool) + 1532 10 com.apple.WebCore 0x01015b94 WebCore::Element::recalcStyle(WebCore::Node::StyleChange) + 628 11 com.apple.WebCore 0x01015e8c WebCore::Element::recalcStyle(WebCore::Node::StyleChange) + 1388 12 com.apple.WebCore 0x01015e8c WebCore::Element::recalcStyle(WebCore::Node::StyleChange) + 1388 13 com.apple.WebCore 0x01015e8c WebCore::Element::recalcStyle(WebCore::Node::StyleChange) + 1388 14 com.apple.WebCore 0x01015e8c WebCore::Element::recalcStyle(WebCore::Node::StyleChange) + 1388 15 com.apple.WebCore 0x01015e8c WebCore::Element::recalcStyle(WebCore::Node::StyleChange) + 1388 16 com.apple.WebCore 0x01015e8c WebCore::Element::recalcStyle(WebCore::Node::StyleChange) + 1388 17 com.apple.WebCore 0x01015e8c WebCore::Element::recalcStyle(WebCore::Node::StyleChange) + 1388 18 com.apple.WebCore 0x01015e8c WebCore::Element::recalcStyle(WebCore::Node::StyleChange) + 1388 19 com.apple.WebCore 0x00fe0aac WebCore::Document::recalcStyle(WebCore::Node::StyleChange) + 1532 20 com.apple.WebCore 0x00e5e60c WebCore::CSSFontSelector::fontLoaded(WebCore::CSSSegmentedFontFace*) + 92 21 com.apple.WebCore 0x00e5b6fc WebCore::CSSFontFace::fontLoaded(WebCore::CSSFontFaceSource*) + 108 22 com.apple.WebCore 0x00ec2a38 WebCore::CachedFont::checkNotify() + 88 23 com.apple.WebCore 0x014d0878 WebCore::Loader::Host::didFinishLoading(WebCore::SubresourceLoader*) + 248 24 com.apple.WebCore 0x014678b0 WebCore::SubresourceLoader::didFinishLoading() + 96 25 com.apple.Foundation 0x961184dc _NSURLConnectionDidFinishLoading + 124 26 com.apple.CFNetwork 0x911c121c sendDidFinishLoadingCallback + 200 27 com.apple.CFNetwork 0x911be150 _CFURLConnectionSendCallbacks + 1612 28 com.apple.CFNetwork 0x911bda94 muxerSourcePerform + 192 29 com.apple.CoreFoundation 0x92b3d374 CFRunLoopRunSpecific + 1312 30 com.apple.HIToolbox 0x966b6d48 RunCurrentEventLoopInMode + 268 31 com.apple.HIToolbox 0x966b6ad4 ReceiveNextEventCommon + 264 32 com.apple.HIToolbox 0x966b69ac BlockUntilNextEventMatchingListInMode + 88 33 com.apple.AppKit 0x95804e1c _DPSNextEvent + 600 34 com.apple.AppKit 0x958047d4 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 116 35 com.apple.Safari 0x00007db0 0x1000 + 28080 36 com.apple.AppKit 0x957fe490 -[NSApplication run] + 740 37 com.apple.AppKit 0x957cee94 NSApplicationMain + 444 38 com.apple.Safari 0x000b65a4 0x1000 + 742820 39 com.apple.Safari 0x00001000 0x1000 + 0 (backtrace ends) registers: Thread 0 crashed with PPC Thread State 32: srr0: 0x00000000 srr1: 0x4000f030 dar: 0x30940000 dsisr: 0x40000000 r0: 0x00000000 r1: 0xbfffc650 r2: 0x09912680 r3: 0x0993b480 r4: 0x00000000 r5: 0x00000086 r6: 0x00000000 r7: 0x0000003f r8: 0x08631c00 r9: 0x00000000 r10: 0x0837fe50 r11: 0x0837fe50 r12: 0x00000000 r13: 0x00000000 r14: 0xa054a478 r15: 0x00000000 r16: 0x00000000 r17: 0x00000001 r18: 0x00000000 r19: 0xa0a74bcc r20: 0xbfffe3e4 r21: 0xbfffd6c8 r22: 0x00000000 r23: 0x00000001 r24: 0x0073c300 r25: 0x00000000 r26: 0x00000000 r27: 0x082ebe40 r28: 0x0837fe40 r29: 0x098f51b0 r30: 0x098f5180 r31: 0x00e872d4 cr: 0x44042448 xer: 0x20000004 lr: 0x014f55f8 ctr: 0x00000000 vrsave: 0x00000000
John Engelhart
Comment 2 2008-10-08 04:24:29 PDT
Created attachment 24190 [details] Tarball with .html + fonts that reproduces the bug You'll need to try printing to tickle the bug. At least, that's the most reliable way I've found to tickle the bug, and the way the example is set up to demonstrate it. All you need to do is Command-P. The standard print sheet dialog will be displayed and it will crash seconds after that.
John Engelhart
Comment 3 2008-10-08 04:35:10 PDT
There is also another potential bug I encountered. I don't want to open another bug and paste the same big tarball in to it just for this one quirk (which may just be a misunderstanding on my part) In the example tarball, you'll either need to uncomment the weird block of html right near the <body> start tag or fix the underlying bug, but you'll need to get a print preview output from the .html. The bug is this: The CSS attribute 'letter-spacing' is not behaving as I expect it should. My understanding is that positive values (letter-spacing: 0.5ex) cause the letters to 'spread out', while negative values cause the letters to 'bunch up'. What I found was the exact opposite is happening, at least in the attached example .html file. The CSS attribute 'letter-spacing' is used exactly once, and that's in the @media print {} section for the LetterGothic font to increase the amount of space between characters for readability. However, I had to use 'letter-spacing: -0.5ex' to get the desired result. Misunderstanding? Or possibly related to 'downloading' the LetterGothic font via @font-face? Sorry about putting two bugs in one ticket, but the tarball for the .html example is kinda big, and seems wasteful to duplicate it in another ticket for something that might just be a misunderstanding on my part. I'm sure someone who reads this and is familiar with such things will be able to instantly flag it as a problem or not.
mitz
Comment 4 2008-11-29 13:22:57 PST
I think the crash is in fact the same as bug 22454.
Yuzo Fujishima
Comment 5 2010-09-12 22:31:30 PDT
Please reopen if the issue persists. *** This bug has been marked as a duplicate of bug 22454 ***
Note You need to log in before you can comment on or make changes to this bug.