Bug 21467 - Hard crash using @font-face w/ src: url(...)
Summary: Hard crash using @font-face w/ src: url(...)
Status: RESOLVED DUPLICATE of bug 22454
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-08 04:17 PDT by John Engelhart
Modified: 2010-09-12 22:31 PDT (History)
2 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description John Engelhart 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).
Comment 1 John Engelhart 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
Comment 2 John Engelhart 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.
Comment 3 John Engelhart 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.
Comment 4 mitz 2008-11-29 13:22:57 PST
I think the crash is in fact the same as bug 22454.
Comment 5 Yuzo Fujishima 2010-09-12 22:31:30 PDT
Please reopen if the issue persists.

*** This bug has been marked as a duplicate of bug 22454 ***