Last Comment Bug 520030 - crash on sites with @font-face used
: crash on sites with @font-face used
Status: RESOLVED FIXED
[should block]
:
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: unspecified
: x86 Linux
: P2 critical (vote)
: mozilla1.9.3a1
Assigned To: Karl Tomlinson (back Dec 13 :karlt)
:
: Milan Sreckovic [:milan]
Mentors:
Depends on: 467874
Blocks: 541966
  Show dependency treegraph
 
Reported: 2009-10-01 11:39 PDT by Bohdan Ganický
Modified: 2010-01-25 06:28 PST (History)
10 users (show)
mbeltzner: blocking1.9.2+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
beta3-fixed
.6-fixed


Attachments
correct cairo version requirements (556 bytes, patch)
2009-10-01 15:30 PDT, Karl Tomlinson (back Dec 13 :karlt)
jd.bugzilla: review+
dveditz: approval1.9.1.6+
Details | Diff | Splinter Review

Description Bohdan Ganický 2009-10-01 11:39:40 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090930 Ubuntu/8.10 (intrepid) Shiretoko/3.5.4pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090930 Ubuntu/8.10 (intrepid) Shiretoko/3.5.4pre

Last days (2 weeks, not sure) I'm experiencing FF crashes on sites with @font-face CSS rule used. Firstly I suspected Typekit.com script to be the sinner. But later on same thing happened on sites without typekit.js - just using the @font-face rule. Example websites:
http://zeldman.com (with Typekit)
http://msgre.tumblr.com/ (with Typekit)
http://jquery.cz (no Typekit, @font-face only)
http://www.blog.spoongraphics.co.uk/ (no Typekit, @font-face only)
...and more

Sometimes FF crashes immediately as I visit the page. Sometimes when I start to scroll with mousewheel. Sometimes when I'm trying to close the page with middle-click on the tab.

(pardon my bad english)

Reproducible: Always




Build platform
target
i686-pc-linux-gnu

Build tools
Compiler 	Version 	Compiler flags
cc 	gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12) 	-Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -Wno-long-long -pedantic -g -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions
g++ 	gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12) 	-fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -g -fno-strict-aliasing -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions

Configure arguments
--build=i486-linux-gnu --prefix=/usr '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' --sysconfdir=/etc --localstatedir=/var '--libexecdir=/usr/lib/xulrunner-1.9.1' --disable-maintainer-mode --disable-dependency-tracking --srcdir=. --enable-tests --enable-mochitest --enable-system-cairo --disable-system-sqlite --with-system-nss --enable-system-hunspell --enable-application=xulrunner --enable-extensions=default,python --with-default-mozilla-five-home=/usr/lib/xulrunner-1.9.1.4pre --enable-safe-browsing --enable-startup-notification --with-user-appdir=.mozilla --without-system-jpeg --with-system-zlib=/usr --with-system-bz2=/usr --disable-javaxpcom --disable-crashreporter --disable-elf-dynstr-gc --disable-installer --disable-strip --disable-strip-libs --disable-install-strip --disable-updater --enable-optimize --with-distribution-id=com.ubuntu
Comment 1 David Baron :dbaron: ⌚️UTC-10 2009-10-01 11:56:25 PDT
If you try a build downloaded from mozilla.com, you could submit crash reports (and then find their ids in about:crashes) that might help us diagnose the problem.
Comment 2 Bohdan Ganický 2009-10-01 12:55:28 PDT
3.5.3 build from Mozilla.com is working flawlessly. I have opened all the mentioned sites at once, browsing, scrolling, tab closing, everything's fine, no crash. So it seems to be an issue with 3.5.4pre daily.
Comment 3 David Baron :dbaron: ⌚️UTC-10 2009-10-01 13:27:03 PDT
Our nightly builds of 3.5.4pre are at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.1/
and those would also have the crash reporter.

(Or is an issue specific to the Ubuntu builds, related to something they patch in their source code or some build option they use?)
Comment 4 Bohdan Ganický 2009-10-01 13:47:46 PDT
I guess you're right. I've just installed the 3.5.4pre build from mozilla.com and it's working flawlessly as well. The crashing build I used before is from Launchpad: https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
Comment 5 Karl Tomlinson (back Dec 13 :karlt) 2009-10-01 14:00:22 PDT
What version of cairo do you have?
You'll need at least 1.8.8 (or patches to fix the bugs in earlier versions) if the Ubuntu build is using system cairo.
Comment 6 Jonathan Kew (:jfkthame) 2009-10-01 14:06:18 PDT
I haven't actually managed to reproduce the crash here, so what follows is
speculation, but FWIW.....

I noticed that both the http://jquery.cz and
http://www.blog.spoongraphics.co.uk/ sites are using a font called Graublau
Web. That's immediately suspicious: is it purely a coincidence, or is this a
broken font? (One site uses it in .ttf format, the other in .otf format, but it
seems that both versions have the same OpenType layout tables).

Loading this font into FontForge, it reports an error in the ligature rules,
and dumping with the font tables with ttx confirms this: there is an invalid
glyph ID in the rule for the "ff" ligature. I can imagine this might easily
cause problems, perhaps depending on the exact versions of pango and/or
freetype that are used.

To demonstrate the brokenness of the font, download it and install locally,
then try a simple test case:

  data:text/html,<p contentEditable style="font-family:Graublau Web;
font-size:48pt;">Hello world!</p>

This will probably display fine. Then click in the text and insert a word with
"ff" in it, and note that where the ligature should appear, it vanishes (and I
wonder if this might trigger a crash in some builds).

I haven't tried to analyze what fonts the TypeKit-based sites are using, as
it's more hassle to reconstruct the data for those. But I suspect there may be
similar invalid font data involved.

If it is indeed this bad font data causing the crash, then it could well be
intermittent depending on the exact text that happens to be on the page; and
accessing the bad data might cause memory corruption, leading to a potential
crash later on, rather than immediate failure.
Comment 7 Bohdan Ganický 2009-10-01 14:16:51 PDT
http://graphicriver.net/ crashes as well, font: MgOpen Modata

Still, why it's crashing the Launchpad build only?

Btw: Cairo version is  1.8.0-0ubuntu1.1
Comment 8 Jonathan Kew (:jfkthame) 2009-10-01 14:53:50 PDT
MgOpen Modata also has errors, as reported on opening the font with FontForge, and confirmed by dumping with ttx; in this case, at least two glyphs (non-breaking space and soft-hyphen) have crazy advance widths that exceed the maximum declared in the horizontal metrics header.

I don't know if this by itself would be sufficient to cause a crash, but it's conceivable if there is code somewhere that doesn't sanity-check metrics values before using them. In addition, seeing such errors suggests that the font was built with poor-quality tools, and certainly not validated carefully before distribution, and so there may well be other errors as well within the font structure, hinting data, layout tables, etc.

As for why you only see the crash with the Launchpad build: my guess is that either it is using different versions of some of the relevant libraries (such as pango, freetype, cairo), or else it just happens that the damage proves non-fatal in some builds because of different memory allocation characteristics or other hard-to-predict factors.
Comment 9 Karl Tomlinson (back Dec 13 :karlt) 2009-10-01 15:30:14 PDT
Created attachment 404141 [details] [diff] [review]
correct cairo version requirements

Looks like system cairo is being used, so this is very likely due to bug 467874.

From
http://launchpadlibrarian.net/32751386/xulrunner-1.9.1_1.9.1.4~hg20090930r26445%2Bnobinonly-0ubuntu2~umd1~intrepid.diff.gz :

+USE_SYSTEM_CAIRO := $(shell pkg-config --exists 'cairo >= 1.6.0'; a=$$?; if test $$a != 1; then echo 1; fi)
+# for old cairo versions we cannot use system cairo
+ifeq (1,$(USE_SYSTEM_CAIRO))
+   EXTRA_SYSTEM_CONFIGURE_FLAGS += --enable-system-cairo
+else
+   EXTRA_SYSTEM_CONFIGURE_FLAGS += --disable-system-cairo
+endif
Comment 10 Bohdan Ganický 2009-10-02 04:31:23 PDT
Does that mean that mozilla.com builds are shipped with its own cairo lib? I guess I'll stick with builds from Mozilla.com then.
Comment 11 John Daggett (:jtd) 2009-10-20 00:01:18 PDT
Should this be applied to 1.9.2 also?
Comment 12 Mike Hommey [:glandium] 2009-10-20 00:12:47 PDT
The problem with cairo vs. font-face is that this is a runtime feature that doesn't impact the ABI. Which means that preventing the use of system cairo when the system cairo version is old won't prevent the problem from happening if the system cairo at runtime is old. This is what happens on debian when people using lenny (old cairo) install the latest iceweasel packages from unstable (firefox 3.5.x). I wonder if there is something that firefox could check at runtime...
Comment 13 Karl Tomlinson (back Dec 13 :karlt) 2009-10-20 00:34:04 PDT
(In reply to comment #10)
> Does that mean that mozilla.com builds are shipped with its own cairo lib?

That's right.
Comment 14 Karl Tomlinson (back Dec 13 :karlt) 2009-10-20 00:36:47 PDT
(In reply to comment #11)
> Should this be applied to 1.9.2 also?

Yes, and 1.9.1 also.
Comment 15 Karl Tomlinson (back Dec 13 :karlt) 2009-10-20 00:59:34 PDT
(In reply to comment #12)
> The problem with cairo vs. font-face is that this is a runtime feature that
> doesn't impact the ABI. Which means that preventing the use of system cairo
> when the system cairo version is old won't prevent the problem from happening
> if the system cairo at runtime is old. This is what happens on debian when
> people using lenny (old cairo) install the latest iceweasel packages from
> unstable (firefox 3.5.x). I wonder if there is something that firefox could
> check at runtime...

Yes, the changes were not feature enhancements but fixes for features that have existed for a long time.  That makes it difficult to determine at runtime whether any particular cairo library has the bug fixed.

I'm actually a little surprised that a firefox built against unstable's glib and libc libraries manages to avoid picking up new dependencies and runs on lenny.

http://bugs.freedesktop.org/show_bug.cgi?id=18862 was a regression so only affects certain versions of cairo.
https://bugs.freedesktop.org/show_bug.cgi?id=21706 may have existed for much longer.
Can these bug fixes be back-ported to lenny's cairo if that version is affected?

It may even be worthwhile for people building with --enable-system-cairo to look at all the patches in gfx/cairo/README and check whether they would be affected by those issues.
Comment 16 Mike Hommey [:glandium] 2009-10-20 01:10:06 PDT
> I'm actually a little surprised that a firefox built against unstable's glib
> and libc libraries manages to avoid picking up new dependencies and runs on
> lenny.

This is possible because of the way the dependencies are calculated with some packages that include symbols file, in which case, depending on the symbols in actual use, dependencies can end up beeing loosened, which helps making a whole lot of packages from testing/unstable installable on stable.

As for firefox, only a few dependencies are required from unstable, such as sqlite.

I guess the best we can do is to force a dependency on a newer cairo (which is also technically possible).
Comment 17 Karl Tomlinson (back Dec 13 :karlt) 2009-10-21 19:49:08 PDT
http://hg.mozilla.org/mozilla-central/rev/e4a200db5497
Comment 18 Daniel Veditz [:dveditz] 2009-11-04 16:18:24 PST
Comment on attachment 404141 [details] [diff] [review]
correct cairo version requirements

Approved for 1.9.1.6, a=dveditz for release-drivers
Comment 19 Karl Tomlinson (back Dec 13 :karlt) 2009-11-08 18:38:54 PST
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/de8b7f3af461
Comment 20 Mike Beltzner [:beltzner, not reading bugmail] 2009-11-11 07:29:14 PST
Please go ahead and land this on 1.9.2; approval not needed as it now blocks.
Comment 21 Karl Tomlinson (back Dec 13 :karlt) 2009-11-11 19:05:04 PST
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/96a63cd3a544

Note You need to log in before you can comment on or make changes to this bug.