[Webkit-unassigned] [Bug 21467] New: Hard crash using @font-face w/ src: url(...)

Wed Oct 8 04:17:14 PDT 2008

https://bugs.webkit.org/show_bug.cgi?id=21467

           Summary: Hard crash using @font-face w/ src: url(...)
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Macintosh
        OS/Version: Mac OS X 10.5
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: john.engelhart at gmail.com

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

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.