Bug 659

Summary: non-XFT builds of Mozilla crash X server when viewing pages with unrecognized unicode characters
Product: xorg Reporter: Hannes Mayer <fedora>
Component: Server/DDX/XorgAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact:
Severity: critical    
Priority: highest CC: gajownik, htl10, mharris, soren.sandmann, t.hartwig
Version: 6.7.0   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
strace startx 2> stracestartx.txt
none
strace mozilla 2> stracemozilla.txt
none
strace -ff -v -o straceX -p PID_OF_X_PROCESS
none
A patch none

Description Hannes Mayer 2004-05-23 04:58:09 UTC
Non-XFT enabled builds (-> official mozilla.org builds; tested 1.7RC1, 1.7RC2,
1.8alpha) crash the X server on Fedora 2 (xorg-x11) when viewing pages with
unrecognized unicode characters.

See the links for examples:

A png of the characters causing the X crash:
http://www.captn.net/character.png

This page with just 2 characters crashes X on Fedora 2 with 1.7RC1, 1.7RC2 and
1.8alpha (non-xft):
http://www.captn.net/mozilla-crash.html
(self built XFT-enabled doesn't crash)

This is especially annoying when such characters appear in google SERP's!

Can't come up with any useful error-messages yet. Reasons:

* X crashes only with:
Fatal server error:
Caught signal 11.  Server aborting

* mozilla -g | tee mozdbg.txt
stops writing to the file as soon as X crashes

If you have any other ideas on getting error messages, I'd be more than happy to
post them.

Thanks a lot!

Reproducible: Always
Steps to Reproduce:
1. Install any recent non-xft mozilla-build on Fedora 2
2. View the page mentioned above
3. X server crashes

Actual Results:  
X server crashed - Fedora-graphical login comes up again. Sometimes hard hang of
the system
Comment 1 Hannes Mayer 2004-06-06 20:44:30 UTC
Created attachment 355 [details]
strace startx 2> stracestartx.txt

I figured out how to use strace for this bug.
On my Fedora-box:
failsave-terminal
# telinit 3
# strace startx 2> stracestartx.txt
Opened mozilla, loaded the crashing-page, X crashed...
Comment 2 Hannes Mayer 2004-06-06 20:45:13 UTC
Created attachment 356 [details]
strace mozilla 2> stracemozilla.txt

This is the strace when logged in in GNOME and calling mozilla from the
terminal.
strace mozilla 2> stracemozilla.txt
Comment 3 Mike A. Harris 2004-07-04 07:49:56 UTC
Someone will probably have to debug both mozilla and the X server at the
same time for this issue in order to determine the problem cause.  They'll
also need to recompile mozilla in order to try to reproduce.

If someone can reproduce this and debug it, that would help a lot to
expediate finding a solution.  Providing prebuilt rpms of a reproducing
mozilla might also help speed things up.

Hope this helps.
Comment 4 Jan Slupski 2004-07-13 15:46:04 UTC
Mine mozilla does not crash with web page from description, but does when searching 
for phrase 'e3-f' in google. With setting of 100 result per page.

http://www.google.com/search?q=e3-f&sourceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8
Comment 5 Mike A. Harris 2004-09-01 04:38:00 UTC
Is there anyone investigating this issue, or any change in status of this
issue?
Comment 6 Hin-Tak Leung 2004-09-06 06:26:25 UTC
I did some digging and I think it is a 
'non-xft build mozilla'<->X-server<->font-server interaction issue.

Ever since I upgraded my office box to fedora2 (from redhat 9) I 
have been biten by mozilla bring down the X server during a 
google search or when displaying pages with strange characters. 
Yesterday I remember I never had a crash with my home box - 
which runs slackware 10; and of course I view pages or do google
search on either in a similar way. And since upgraded to
fedora 2, both are running Xorg 6.7.0, with the official 
mozilla 1.7.2 build, so the two boxes are version-wise similar -
with one difference - my home box doesn't use font server
but have static font paths. 

So I did a bit of playing around on my office fedora 2 box.
Installed both the fedora 2 xft-enabled mozilla and the official
non-xft build. And yes, I can reproduce the X-server crash with
the non-xft reliably, while the xft-enabled build survives.

Then I modified /etc/X11/xorg.conf to use static font paths instead
of the font server, and the non-xft build doesn't crash the 
x-server anymore. I put the font server fontpath entry back *after*
the static font paths (i.e. static font path + font server),
and the non-xfs build doesn't crash the X-server either.
So I think I am inclined to leave the config like that -
static font paths + font server. This way everything
should just work fine.

Can somebody please remind me, what's the benefit of 
using a font server versus static font paths again? 
(besides having crashes like this, that is :-).
Comment 7 Hin-Tak Leung 2004-09-08 06:44:35 UTC
putting unix:7100 before the static font paths in xorg.conf
also crashes the X server; so it seems that the safe option is
to put the static font path before the font server entry.
Comment 8 Thomas Hartwig 2004-11-15 01:56:32 UTC
I can confirm this bug on a ati radeon card on Fedora 2, please see my report in
mozilla bugzilla.

https://bugzilla.mozilla.org/show_bug.cgi?id=269753

The workaround of Hin-Tak Leung worked for me as well, thank you very much for
investigating this.
Comment 9 Dawid Gajownik 2004-11-25 06:33:12 UTC
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121403#c24 &#8592; I've made here
report how to reproduce this bug (freedesktop.org was down in that time).

Maybe some developer would be able to investigate it further...
Comment 10 Dawid Gajownik 2004-12-29 02:39:11 UTC
Created attachment 1603 [details]
strace -ff -v -o straceX -p PID_OF_X_PROCESS

I do not know whether it is useful but here is strace of X process when it
crashes.
Comment 11 Søren Sandmann Pedersen 2005-03-04 07:30:02 UTC
Created attachment 2016 [details] [review]
A patch

This patch fixes

     https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136450

which has very similar symptoms to this bug.
Comment 12 Søren Sandmann Pedersen 2005-03-04 07:42:20 UTC
The patch needs s/calloc/xcalloc/ and s/free/xfree/ .
Comment 13 Søren Sandmann Pedersen 2005-03-04 07:44:54 UTC
The Red Hat bug URL should be

   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145546
Comment 14 Dawid Gajownik 2005-03-21 10:27:37 UTC
May someone review this patch and check it in? I'm using patched version of
X.org X11 6.8.2 from Fedora's development tree and X server does not crash
anymore :D 

BTW thanks for your patch! My nightmare is over -- no more lost data :)
Comment 15 Hin-Tak Leung 2005-03-26 22:00:51 UTC
official non-xft Mozilla 1.7.6. + xorg 6.8.2 + unix/:7100 at the 
beginning + xfs doesn't crash X any more, with the test page.
Comment 16 Dawid Gajownik 2005-03-27 07:55:14 UTC
(In reply to comment #15)
> official non-xft Mozilla 1.7.6. + xorg 6.8.2 + unix/:7100 at the 
> beginning + xfs doesn't crash X any more, with the test page.

Well, I've just recompiled xorg-x11-6.8.2-13 SRPM from Fedora's development tree
(I've only disabled this patch in SPEC file ->
http://cvs.fedora.redhat.com/viewcvs/devel/xorg-x11/xorg-x11-6.8.2-fix-font-crash.patch
) and I was able to crash X server on this page ->
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=106786&action=view :/

Above patch resolves the problem :)
BTW I use Mozilla 1.8b if it makes any differance.
Comment 17 Daniel Stone 2005-07-04 14:11:16 UTC
Søren, if this is still good, please commit.
Comment 18 Søren Sandmann Pedersen 2005-08-12 01:47:35 UTC
Committed to HEAD.

Thu Aug 11 11:43:32 2005  Søren Sandmann  <sandmann@redhat.com>

	* programs/Xserver/hw/xfree86/xaa/xaaTEText.c
	(XAAGlyphBltTEColorExpansion): Make sure we don't
	crash on glyphs with NULL bits. Bug 659.

Comment 19 Søren Sandmann Pedersen 2005-08-12 01:49:45 UTC
Created attachment 3325 [details] [review]
use wnck and don't show notifications if another window is fullscreen
Comment 20 Adam Jackson 2005-10-22 15:49:11 UTC
(In reply to comment #18)
> Committed to HEAD.

therefore marking as FIXED.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.