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.

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

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

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.

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.

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

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.

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

(In reply to comment #10) > Does that mean that mozilla.com builds are shipped with its own cairo lib? That's right.

(In reply to comment #11) > Should this be applied to 1.9.2 also? Yes, and 1.9.1 also.

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

Comment on attachment 404141 [details] [diff] [review] correct cairo version requirements Approved for 1.9.1.6, a=dveditz for release-drivers

Please go ahead and land this on 1.9.2; approval not needed as it now blocks.