Bug 164664 - Firefox crashes with cairo assertion
Firefox crashes with cairo assertion
Product: Fedora
Classification: Fedora
Component: cairo (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kristian Høgsberg
: 164626 164726 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2005-07-29 16:07 EDT by Anders Kaseorg
Modified: 2007-11-30 17:11 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-08-03 22:12:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
GDB log (12.56 KB, text/plain)
2005-07-29 16:07 EDT, Anders Kaseorg
no flags Details

  None (edit)
Description Anders Kaseorg 2005-07-29 16:07:20 EDT
Description of problem:
Firefox is very unstable in current rawhide; it usually crashes just scrolling
up and down on one page. Here's part of the gdb backtrace that leads me to
believe this is a cairo problem (the rest is attached).

firefox-bin: cairo.c:86: _cairo_error: Assertion `status > CAIRO_STATUS_SUCCESS
&& status <= CAIRO_STATUS_FILE_NOT_FOUND' failed.

Program received signal SIGABRT, Aborted.

#0  0x00e7b402 in __kernel_vsyscall ()
#1  0x00f5c7d8 in raise () from /lib/libc.so.6
#2  0x00f5df28 in abort () from /lib/libc.so.6
#3  0x00f559b5 in __assert_fail () from /lib/libc.so.6
#4  0x0070af9d in ?? () from /usr/lib/libcairo.so.1
#5  0x0070afae in ?? () from /usr/lib/libcairo.so.1
#6  0x0047bfaa in pango_cairo_renderer_get_type ()
   from /usr/lib/libpangocairo-1.0.so.0
#7  0x004c47d9 in pango_renderer_draw_glyphs () from /usr/lib/libpango-1.0.so.0
#8  0x0047c4b9 in pango_cairo_show_glyph_string ()
   from /usr/lib/libpangocairo-1.0.so.0
#9  0x007a807a in gdk_pango_renderer_get_type ()
   from /usr/lib/libgdk-x11-2.0.so.0
#10 0x004c47d9 in pango_renderer_draw_glyphs () from /usr/lib/libpango-1.0.so.0
#11 0x004c593a in pango_renderer_draw_layout_line ()
   from /usr/lib/libpango-1.0.so.0
#12 0x007a92d2 in gdk_draw_layout_line_with_colors ()
   from /usr/lib/libgdk-x11-2.0.so.0
#13 0x007a93d8 in gdk_draw_layout_line () from /usr/lib/libgdk-x11-2.0.so.0

Version-Release number of selected component (if applicable):
cairo-0.6.0-1, pango-1.9.1-1, gtk2-2.7.4-1

How reproducible:

Steps to Reproduce:
1. Open firefox.
2. Load http://slashdot.org/.
3. Scroll up and down a few times.

Actual results:
Firefox crashes.
Comment 1 Anders Kaseorg 2005-07-29 16:07:20 EDT
Created attachment 117294 [details]
GDB log
Comment 2 Bill Nottingham 2005-07-29 20:13:34 EDT
*** Bug 164626 has been marked as a duplicate of this bug. ***
Comment 3 Mike Chambers 2005-07-29 21:56:34 EDT
It doesn't just crash when scrolling up and down.  I can click on some links, it
starts to open and crashes right then and there.
Comment 4 Mickey Stein 2005-07-30 09:26:57 EDT
If you uncomment the PANGO lines:

## Set MOZ_ENABLE_PANGO is no longer used because Pango is enabled by default
## you may use MOZ_DISABLE_PANGO=1 to force disabling of pango

Then https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163692 is another bug
I started a few weeks ago that is about the instabilities sans the above statements.

When the first deerpark version appeared in rawhide, it appeared that
cairo-pango versions wouldn't show fonts correctly and also added another degree
of instability (when switching tabs, the dropdown menu dawdling bug, etc). 

When PANGO is uncommented, the nature of the bugs is at least a bit more subtle,
and seems very centered on buttons being clicked in various dialog boxes. No
trace is ever given on exit, regardless of debug symbols, method of debug etc.
For me, all the deerpark, and I think the one 1.0.6 ff version all have had the
exact same instabilities. 

The only other thing I really notice with the clicking buttons/ctd phenomenon is
that clicking them 5-10 seconds after they appear onscreen (e.g. clicking close
on the about:firefox box), will work 90% of the time, while clicking them
immediately will fail more than 1/2 the time. 

I doubt I can get any more vague ;), so I'll leave it at that for now.
Comment 5 Rodd Clarkson 2005-07-31 07:23:14 EDT
*** Bug 164726 has been marked as a duplicate of this bug. ***
Comment 6 Mike Chambers 2005-07-31 10:08:35 EDT
Ok, don't know if this would help or if it's related, but the below mozilla
version doesn't seem to crash like firefox, with same plugins.  I haven't tried
with today's rawhide verison of mozilla yet, as there is a dependency of
epiphany that stops it.

Comment 7 Mickey Stein 2005-07-31 11:29:11 EDT
mozilla-1.7.11-1 (today's version on rawhide) crashed on the 7th click of a
cancel button in any dialog box. I tried it 3 more times, and it crashed within
1-9 clicks of either a cancel or ok button. The dialog box I used most (just for
info purposes) was the 'file bookmark' and 'cancel' button within it.
mozilla-1.7.10-3 did the same for me earlier on in this bug cycle.

I wonder if these crashes are at all related to cairo, although font & display
issues have seemed related to pango/cairo lately. Isn't cairo primarily about
print & display output & renderaccel? If that's true, I'm not seeing how the
handling of a button click could be cairo-related. Anyway, I mentioned a
bugzilla report in #4 that is non-cairo related and more about the input issue.

Comment 8 Nicolas Mailhot 2005-08-01 09:07:40 EDT
I strongly suspect this is related to problems with the cairo backend - I had
similar crashes with evince yesterday, like in firefox it seems triggered merely
by scrolling a page with heavy formatting.

Like you say moz seemed a bit more stable for a while but it has gained parity
with firefox lately
Comment 9 Dennis Jacobfeuerborn 2005-08-01 11:16:18 EDT
Looks more like a pango problem to me. I've uncommented the pango lines in
/usr/bin/firefox as mentioned above and didn't see a single crash since despite
extensive use.
Comment 10 Mickey Stein 2005-08-01 11:48:14 EDT
This is the 'buildconfig' used on firefox-1.1-0.2.5.deerpark.alpha2, (just one
of the trio of crashing mozilla.org packages):



Build platform

Build tools
Compiler 	Version 	Compiler flags
gcc 	gcc version 4.0.1 20050729 (Red Hat 4.0.1-6) 	-Wall -W -Wno-unused
-Wpointer-arith -Wcast-align -Wno-long-long -pedantic -pthread -pipe
c++ 	gcc version 4.0.1 20050729 (Red Hat 4.0.1-6) 	-fno-rtti -fno-exceptions
-Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic
-fshort-wchar -pthread -pipe -I/usr/X11R6/include

Configure arguments
--enable-application=browser --with-system-nspr --with-system-jpeg
--with-system-zlib --with-system-png --with-pthreads --disable-tests
--disable-debug --disable-installer '--enable-optimize=-Os -g -pipe
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4
-fasynchronous-unwind-tables' --enable-xinerama --enable-default-toolkit=gtk2
--disable-xprint --disable-strip --enable-pango 


That translates (by ./configure defaults to) 

the above +

(or so it says in my config.log)

I'm building it right now using this .config (well, the 3 last options for sure):
. $topsrcdir/browser/config/mozconfig
ac_add_options --disable-pango
ac_add_options --disable-system-cairo
ac_add_options --disable-svg-renderer
ac_add_options --disable-svg


Firefox takes quite awhile to build (over an hour) for me, so I'll check it out
for crashes when I get back from work. If it works, I'll start peeling away
pieces of the disable-* config options.
Comment 11 Mickey Stein 2005-08-01 12:01:18 EDT
Anyway: it seems that there's possibly two (or more) fronts of the mozilla/ff/tb

1) Output side, having to do with pango, cairo, (or so we think)
2) Input side, or crashes that occur when clicking on a button in a dialogue, or
a link occasionally.

If whatever I try above with my own FF builds proves that pango & cairo get rid
of #1 and #2 then I'll reply back here later on, but if not, I'll just go on
with the bug I started having only to do with the Input side crashes. This bug
is over at:


I think this other set of problems detailed over at 163692 were concurrent with
some rawhide gnome* gtk* packages as to when they began.
Comment 12 Erich Hoover 2005-08-01 14:53:16 EDT
1) If you load the firefox binary manually (LD_LIBRARY_PATH=/usr/lib/firefox-1.1
/usr/lib/firefox-1.1/firefox-bin) the error indicates a problem with cairo:
firefox-bin: cairo.c:86: _cairo_error: Assertion `status > CAIRO_STATUS_SUCCESS
&& status <= CAIRO_STATUS_FILE_NOT_FOUND' failed.

2) A problem I've been having since the same round of updates has been that my
GNOME panel only works on a single desktop at a time - could this be related?

Problems occur with both i386 and x86-64.
Comment 13 Anders Kaseorg 2005-08-01 15:14:58 EDT
Yes, I noted the cairo assertion in my initial report and the bug summary. For
reference, the easiest way to get firefox (or mozilla) to give debugging output
is to close all firefox windows, then run firefox -g, which loads firefox in
gdb. (Did Mickey, the author of comment #4, try this?)

I don't see the panel problem; you should open a separate bug.
Comment 14 Mickey Stein 2005-08-01 22:00:02 EDT
Anders, I would've but you beat me to it ;) My debug-enabled build blew apart
while I was at work, so more on that another time. 

I'll stick to the other thread since my main gripe (buttons buttons buttons)
seems like a gtk thing (courtesy of Anders) and a Cairo component which is
really this bugzilla entry. 

I also don't see *that* panel problem, but there's another bug around (I think I
started, don't recall, in any case, it didn't belong as specific to fedora)
about the panel causing kicker to segfault upon GUI exit, but this is
acknowleged as fixed in the next rawhide release (or so I recall, which is
suspect at this point of the day ) This one may have gotten tossed upstream to
freedesktop.org or some such place. 

Comment 15 Mickey Stein 2005-08-02 11:21:18 EDT
I guess I can't keep away from this, but this topic seems related over in the
mozillazine forums:


And I'm currently trying builds with an .configure option I knew nothing of
before this: (--enable-system-cairo (use the $pkg-config cairo --libs --cflags
query) or --disable-system-cairo (use mozilla.org's 'internal cairo')) 

I can't really tell which is the default although $pmap -x pid(running
firefox-bin) leads me to think that --enable-system-cairo is the default. More
waiting for builds to complete and eventually see if that does anything.

Has anyone else tried playing with those options? 
Comment 16 Kristian Høgsberg 2005-08-02 14:49:17 EDT
I've built cairo-0.6.0-2 in rawhide, with a patch from cairo CVS (related to
font options and font caching).  With this build, I can no longer reproduce the
crashes described in this bug.  Please give it a try once it hits rawhide and
let me know if it fixes your problems.
Comment 17 Dennis Jacobfeuerborn 2005-08-03 08:51:41 EDT
I have been using firefox with the new cairo release for a couple of minutes now
and it seems the problem is fixed. Good work!
Comment 18 Christopher Aillon 2005-08-03 10:13:14 EDT
*** Bug 163692 has been marked as a duplicate of this bug. ***
Comment 19 Mickey Stein 2005-08-03 11:50:42 EDT
The new cairo fixes this bug (as described by the reporter), but
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163692 isn't related. I
left it open and posted a patch there that I found over on gnome bugzilla for an
identical (nearly) stack trace. Check out that bug if you're having crashing
problems *only due* to various clicks on buttons in dialogues. See 163692 and if
you can build your own ff/tb/moz then you can try out the patch and see if that
is of any use. I can crash it endlessly with this new rawhide cairo package, but
I can't seem to crash it (yet ;)) with the patch applied and firefox built over it. 
Comment 20 Sigge Kotliar 2005-08-03 21:47:47 EDT
Firefox does in deed seem much more stable with cairo 0.6.0-2.
Have been using it for three hours, including the usual crashers: tabs,
scrolling, middleclicking, slashdot et cetera.

Confirming what Dennis J reported: the bug seems fixed! 

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