Closed
Bug 187473
Opened 22 years ago
Closed 12 years ago
xfs and X server deferglyphs causes hang on large fonts
Categories
(Core :: Layout: Text and Fonts, defect, P1)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: idallen, Unassigned)
Details
(Keywords: hang)
Attachments
(2 files)
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.
Reporter | ||
Comment 1•22 years ago
|
||
Updated•22 years ago
|
Priority: -- → P1
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)
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 :(
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•21 years ago
|
||
Ian: is this still a problem (with recent Mozilla builds)? are either of you using xinerama? that's bug 136362.
Keywords: hang
Reporter | ||
Comment 6•21 years ago
|
||
(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•21 years ago
|
||
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.
Summary: xfs and X server deferglyphs causes hang on UTF fonts → xfs and X server deferglyphs causes hang on large fonts
Reporter | ||
Comment 8•21 years ago
|
||
(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•21 years ago
|
||
> --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).
Reporter | ||
Comment 10•21 years ago
|
||
(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•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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.
Reporter | ||
Comment 14•20 years ago
|
||
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•20 years ago
|
||
(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•19 years ago
|
||
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•15 years ago
|
||
Is this still an issue with a recent build ?
Updated•15 years ago
|
Assignee: layout.fonts-and-text → nobody
QA Contact: ian → layout.fonts-and-text
Comment 19•12 years ago
|
||
Comment 20•12 years ago
|
||
Resolved per whiteboard
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
Whiteboard: closeme INCO 2012-09-01
You need to log in
before you can comment on or make changes to this bug.
Description
•