crash on sites with @font-face used

RESOLVED FIXED in mozilla1.9.3a1

Status

()

Core
Graphics
P2
critical
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: Bohdan Ganický, Assigned: karlt)

Tracking

unspecified
mozilla1.9.3a1
x86
Linux
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 +

Firefox Tracking Flags

(status1.9.2 beta3-fixed, status1.9.1 .6-fixed)

Details

(Whiteboard: [should block])

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
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
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.
Component: Style System (CSS) → Graphics
QA Contact: style-system → thebes
(Reporter)

Comment 2

8 years ago
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.
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?)
(Reporter)

Comment 4

8 years ago
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
(Assignee)

Comment 5

8 years ago
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.
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.
(Reporter)

Comment 7

8 years ago
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
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.
(Assignee)

Comment 9

8 years ago
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
Assignee: nobody → mozbugz
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Updated

8 years ago
Attachment #404141 - Flags: review?(jdaggett)
(Assignee)

Updated

8 years ago
Depends on: 467874
(Reporter)

Comment 10

8 years ago
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.

Updated

8 years ago
Attachment #404141 - Flags: review?(jdaggett) → review+

Comment 11

8 years ago
Should this be applied to 1.9.2 also?
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...
(Assignee)

Comment 13

8 years ago
(In reply to comment #10)
> Does that mean that mozilla.com builds are shipped with its own cairo lib?

That's right.
(Assignee)

Comment 14

8 years ago
(In reply to comment #11)
> Should this be applied to 1.9.2 also?

Yes, and 1.9.1 also.
(Assignee)

Comment 15

8 years ago
(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.
> 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).
(Assignee)

Comment 17

8 years ago
http://hg.mozilla.org/mozilla-central/rev/e4a200db5497
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
(Assignee)

Updated

8 years ago
Attachment #404141 - Flags: approval1.9.2?
Attachment #404141 - Flags: approval1.9.1.5?
Comment on attachment 404141 [details] [diff] [review]
correct cairo version requirements

Approved for 1.9.1.6, a=dveditz for release-drivers
Attachment #404141 - Flags: approval1.9.1.6? → approval1.9.1.6+
Flags: blocking1.9.2?
(Assignee)

Comment 19

8 years ago
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/de8b7f3af461
status1.9.1: --- → .6-fixed
Whiteboard: [should block]
Please go ahead and land this on 1.9.2; approval not needed as it now blocks.
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P2
(Assignee)

Comment 21

8 years ago
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/96a63cd3a544
status1.9.2: --- → final-fixed
(Assignee)

Updated

8 years ago
Attachment #404141 - Flags: approval1.9.2?
Blocks: 541966
You need to log in before you can comment on or make changes to this bug.