187473 - xfs and X server deferglyphs causes hang on large fonts

Status: RESOLVED INCOMPLETE

(Core :: Layout: Text and Fonts, defect, P1)

Description

[Ian! D. Allen]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212

Given the use of the X Font Server (xfs) and an X server started with
"-deferglyphs 16", then when Mozilla tries to render a page containing
UTF-8 characters (e.g. Chinese?) in an odd point size, Mozilla locks up
and hangs forever.  (So does Netscape7; Netscape6 does not.)

This does not happen if xfs is not used.

Reproducible: Always

Steps to Reproduce:
Mandrake 8.2 uses xfs to serve fonts.  My X server font path is "unix/:-1".
To simplify the bug report, in my xfs config file I set my font path to just:

    catalogue = /usr/X11R6/lib/X11/fonts/misc

If I start the X server using:

    xinit -- :0 -deferglyphs 16

then when Mozilla tries to render a page containing UTF-8 characters
(e.g. Chinese?) in an odd point size, Mozilla locks up and hangs forever.

If I start the X server with "-deferglyphs none", mozilla loads the
UTF-8 page just fine; or, if I do:

    xset fp /usr/X11R6/lib/X11/fonts/misc

(bypassing the use of xfs), mozilla also loads the UTF-8 page just fine,
even when the X server is started with "-deferglyphs 16".

If I use "-deferglyphs all", font-related things don't load properly even
for other applications such as Eterm, and they appear to misbehave too.

(So the problem isn't strictly a Mozilla problem; but, surely Mozilla
could handle it better, instead of hanging forever?  I get no talkback
dialog for hung mozilla programs - this has been going on for months
[including Netscape7] until I isolated it today.)
Actual Results:  
Hung browser.  Ignores "close window" events.  Had to kill the application.

Expected Results:  
Show me the nice Asian pictograms in the font.

HTML sample page will be attached.

Comment 1

[Ian! D. Allen]

Attachment: HTML UTF-8 sample that hangs mozilla under xfs

Comment 2

[slava]

I also have this problem. Especially then search for something in google :( As I
see, this problem very depend from fonts used. All was OK with original fonts
from RH 9.0, but problem appear after I install ttf fonts from windows. But your
link is work at my system well. I think becouse we use different fonts. And as I
see, the bug unkonfirmed as result of this font dependent problem :( 
I fink, what it is possible to reproduce bug by do this steps:
1) Download ttf fonts I use from here:
http://www.winchat.kiev.ua/MozXfsBug/ttf-win.tar.bz2
Unpack this to any directory and add this directory to your xfs config.
2) This step not neccesary I think, but at my system is. Skip this step, and try
to make all in step 2 only if you don't reproduce bug without it.
Then get fonts.dir and fonts.scale from here:
http://www.winchat.kiev.ua/MozXfsBug/fonts.dir
http://www.winchat.kiev.ua/MozXfsBug/fonts.scale
Replace fonts.dir and fonts.scale in directory, to which you was unpack archive
with new, you download. Make fonts.* imunable (chattr +i fonts.* in this
direcotory). Then make touch "fonts.dir" (to avoid autorebuilding by xfs).
Stop your font server. start it. If you have error with "access deny fonts.*",
repeat touch fonts.*, then stop xfs and start it again.
3)I think you skip "2", if so, restart xfs. then startx and start mozilla.
4) Go here:
http://global.benq.com/www/major/products/product.asp?page=dc3410_techspecs
This link is give "page not found 404" in chinese, as I understand (sorry I
don't know cinese :). And wait for page open. 
5) Your mozilla and your xfs will be dead after some time. 
Thats all folks :(
Anyway, for reproduce this bug, you must use the same fonts as the fonts used at
the linux box, from which the bug was reported.
Also I think, that the bugs 215887, 221193, and this bug is the one bug, not
three different bugs !
I use Mozilla 1.5rc2 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5)
Gecko/20030917)

Comment 3

[slava]

And starting X server with:
startx -- -deferglyphs none
Is help for me too. Try to set deferglyphs to none in xfs config is not help.
This problem also Is was not appear in Mozilla 1.4 as I remember. I was install
the same fonts earlier with 1.4 and all was work well. Problem appear into
mozilla 1.5 in the 1.5rc1 or near it. I can not remember exactly :(

Comment 4

[slava]

Excuse me, the last message is mistakes :( It's only "look like" that
-deferglyphs is help. With it, mozilla is display "chinese" text, and don't die
imediatelly. But  xfs is die after mozilla is display "chinese" and mozilla is
die later, without fontserver. Also about don't use the font server (use
rendering with X itself). If you use the same fonts as in font server, then die
X itself :( This is very,very bad problem :( And only one workaround now - to
disable some ttf (unicode ?) fonts :( 

Comment 5

[Andrew Schultz]

Ian: is this still a problem (with recent Mozilla builds)?

are either of you using xinerama? that's bug 136362.

Comment 6

[Ian! D. Allen]

(In reply to comment #5)
> Ian: is this still a problem (with recent Mozilla builds)?

It hasn't been a problem in recent builds, no.
I currently use Mandrake 9.2 with Mozilla/5.0 (X11; U; Linux i686; en-US; 
rv:1.5) Gecko/20031015.  X is started using:
  xinit /home/idallen/.xinitrc -- :6 -deferglyphs 16
and everything still works.

XFree86 Version 4.3.0
Release Date: 9 May 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: Linux 2.4.19-36mdkenterprise i686 [ELF]
Build Date: 10 December 2003

Comment 7

[Jungshik Shin]

Ian, can you check whether what you use is an X11core build or an Xft build?
Type 'about:buildconfig' in the url (location) bar and see if there's
'enable-xft' in the output.

Comment 8

[Ian! D. Allen]

(In reply to comment #7)
> Ian, can you check whether what you use is an X11core build or an Xft build?
> Type 'about:buildconfig' in the url (location) bar and see if there's
> 'enable-xft' in the output.

about:buildconfig

Build platform
target
i686-pc-linux-gnu

Build tools
Compiler 	Version 	Compiler flags
gcc 	gcc version 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk) 	-Wall -W -Wno-unused
-Wpointer-arith -Wcast-align -Wno-long-long -pthread -pipe
c++ 	gcc version 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk) 	-fno-rtti
-fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-long-long -fshort-wchar
-pthread -pipe -I/usr/X11R6/include

Configure arguments
--prefix=/usr --libdir=/usr/lib '--enable-optimize=-O2\ -fomit-frame-pointer\
-pipe\ -march=i586\ -mcpu=pentiumpro' --disable-debug --disable-pedantic
--enable-strip --disable-tests --enable-crypto --enable-nspr-autoconf
--with-default-mozilla-five-home=/usr/lib/mozilla-1.5 --enable-extensions
--disable-short-wchar --enable-xinerama --enable-mathml --without-system-nspr
--with-system-zlib --enable-ipv6 --enable-old-abi-compat-wrappers
--mandir=/usr/share/man --enable-xft --disable-freetype2
--enable-default-toolkit=gtk2 

Comment 9

[Jungshik Shin]

> --mandir=/usr/share/man --enable-xft --disable-freetype2

What you have now is an Xft build which doesn't use X11core fonts served by
xfs/X11 server. To check if this bug is still present, you have to try an
X11corefont build. Linux nightly builds available at ftp.mozilla.org are
X11corefont builds (unless they're explicitly labelled as 'Xft' builds).

Comment 10

[Ian! D. Allen]

(In reply to comment #9)
> > --mandir=/usr/share/man --enable-xft --disable-freetype2
> What you have now is an Xft build which doesn't use X11core fonts served by
> xfs/X11 server. To check if this bug is still present, you have to try an
> X11corefont build. Linux nightly builds available at ftp.mozilla.org are
> X11corefont builds (unless they're explicitly labelled as 'Xft' builds).

I can do that; but, I don't speak "Mozilla build language".  On ftp.mozilla.org
I found the "nightly" directory; but, it contains things called "08-trunk" and
"09-trunk" and "08-1.4.1" and "09-1.6" and "latest" (which maybe contains all
of the previous?) and I don't know what you want me to try.  I suspect I want
the "09-trunk" directory for my Linux with Athlon CPU; but, even within that
there are unexplained (no README) varieties of tar file such as:
mozilla-i686-pc-linux-gnu-full-installer.tar.gz  
mozilla-i686-pc-linux-gnu-installer.tar.gz 	
mozilla-i686-pc-linux-gnu.tar.gz 
Being unfamiliar with Mozilla builds, I am baffled as to why the installer is
100KB but the "full" installer is 12MB, and the plain gnu.tar.gz file (no
installer?, whatever that means) is even bigger at 13MB.  Surely a build that
includes an installer should be bigger than one that does not?  Perhaps I
don't know what "installer" means in Mozilla Build Language.  A "README" file
in each FTP subdirectory would explain all this and save me having to become
a Mozilla Build Guru just to know what to download.

Comment 11

[Jungshik Shin]

You can try one of those with '-trunk'.  '-1.6' and '-1.4' indicate that they're
1.6 and 1.4 branch builds.  '-latest' is used for  a symbolic link to the latest
trunk build. (in your example, '09-trunk' is the same as '-latest'). 

> why the installer is 100KB but the "full" installer is 12MB, and the plain 
> gnu.tar.gz file (no installer? ..) is 13MB

  The installer included in the installerr package downloads necessary files
over the network when you run it. On the other hand, the full installer does
include those files so that files are read from your local disk when you run the
installer included in the full installerr package. As to why the full installer
package is larger than tar-gzipped package, I have little idea. Perhaps, they
have different build options or different compression methods are used. 

Comment 12

[Roland Mainz]

Uhm... why don't you simply disable Xft usage ?
Assuming the build was not compiled with --disable-xprint (AFAIK otherwise the
neccesary encoding converter code may be missing) you can simply disable Xft
usage in Mozilla like this:
% export GDK_USE_XFT=0
% ./mozilla

Comment 13

[Jungshik Shin]

You're right. I don't know how I forgot to tell him about that.

% env GDK_USE_XFT=0 mozilla 

would be better, though.

Comment 14

[Ian! D. Allen]

This is under Linux Mandrake 9.2.  Kernel  2.4.22-28mdk-i686-up-4GB

---------------------------------

I start XFree86 running (via startx -> xinit) and it looks like this:

    /etc/X11/X :0 -deferglyphs 16

I use a custom .xinitrc that has only "xterm" in it - no window manager,
no Desktop, no menu bars, nothing.  This is my installed mozilla:

    Mozilla 1.5 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031015

In the plain xterm that is started (no window manager), I did this:

    $ rm -rf $HOME/.mozilla
    $ env GDK_USE_XFT=0 mozilla

(Boy do some of the fonts look ugly when run that way!  My menus and title
bars appear in a badly-rendered Times-like font instead of sans-serif
and it is UGLY.)

I can't type more than one character into the location bar!  It accepts
the one character and then no more.  Mouse cut and paste works fine.
In fact, if I highlight some text in the browser window, then click
on the highlighted text and drag it aside a few pixels and let go,
then I return to the location bar and click on it, I can type *one*
more character.  Repeating lets me type one more, etc.

I exited mozilla (using the mouse), and tried this:

    $ env GDK_USE_XFT=0 mozilla /tmp/i.html

File "i.html" contains the problem HTML with the UTF-8 characters.
Mozilla hung.  Without a window manager, there was no way to see the
hung window; but, if I went back to a console and ran "twm -display :0"
it put window borders and titles on everything and showed that there
was a hung mozilla window on the display.

I restarted X and mozilla.  I found that where the location bar only
accepted one character, I could use the mouse to open the "open web"
dialog box and enter a full file name.  I entered "/tmp/i.html" into it
and Mozilla hung again.

I kill mozilla (not X) and restart mozilla.  It works the second time
and all subsequent times.

If I restart the X server and then mozilla, mozilla hangs the first time,
every time, when opening that UTF-8 file.

---------------------------------

Using this newer version of Mozilla from the web page, installed into
/tmp/mozilla:

    Mozilla 1.7a Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040218

I start X as above (no window manager - xterm only) and mozilla like this:

    $ rm -rf $HOME/.mozilla
    $ cd /tmp/mozilla
    $ env GDK_USE_XFT=0 ./mozilla

I can't type anything at all into this mozilla!  I can't type anything
into the location bar, and any dialogs that open also don't accept input!
Nothing I can do will make any of the text fields accept input.
Mouse cut and paste works fine.

I exited mozilla (using the mouse), and tried this:

    $ env GDK_USE_XFT=0 ./mozilla /tmp/i.html

The first rendering of the problem UTF file has almost no Asian characters
visible - most of the characters are just blank spaces.  A "Reload" fixes
the display, and the Asian characters display fine.  Subsequent reloads
of mozilla have no problem with the UTF file.  Restarting X and then
mozilla results in blank spaces again, until a Reload.

Just on a whim, I started a simple window manager and restarted mozilla:

    $ ( twm & )
    $ env GDK_USE_XFT=0 ./mozilla

Okay, now I can enter text into the location bar in this mozilla, and
the dialog boxes also work.  Without the window manager, I cannot enter
any text at all.  That doesn't seem right.

I can't see any difference at all between GDK_USE_XFT=0 and GDK_USE_XFT=1;
they both behave the same way in this build.

Comment 15

[Jungshik Shin]

(In reply to comment #14)

> Without the window manager, I cannot enter
> any text at all.  That doesn't seem right.

 Please, file a new bug (if it's not filed already).

> I can't see any difference at all between GDK_USE_XFT=0 and GDK_USE_XFT=1;
> they both behave the same way in this build.

That's because the default nightly/release build at mozilla.org is not an Xft
build but an X11core build. For X11core builds, GDK_USE_XFT doesn't make any
difference.

Comment 16

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 17

[Matthias Versen [:Matti]]

Is this still an issue with a recent build ?

Comment 18

[Phoenix]

Is this still reproducible/actual?

Comment 19

[[:Aleksej]]

Attachment: The HTML part of attachment 110514

Comment 20

[Phoenix]

Resolved per whiteboard