From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 BuildID: 2002020415 Mozilla starts using a lot of memory, which leads to violent swapping. The browser is instantly unresponsive and quickly brings the machine down if not killed. No "save as" dialog box is ever shown. Reproducible: Always Steps to Reproduce: 1. visit the referenced URL. Actual Results: See description Expected Results: Display a "save as" dialog box.
On build 2002020405 with Mac OS 9.1, Mozilla opens the file and displays it instead of starting download...
The file is served as text/plain so we _should_ show it, not download it. I can't reproduce the swapping behavior on current (from this morning) Linux builds. Memory usage goes up aboug 3MB when opening the page (makes sense, for a largish file). Flavio, could you possibly test a recent nightly?
I've just tested with 2002020809 and the problem persists. In any case, I wouldn't call this a largish file: it's only 22KB big. Any suggestions?
This is related to XFree 4.2.0's font server and true type fonts. Commenting my ttf directory in xfs's config makes Mozilla display the .tar.gz as usual and fixes the problem. Other apps work fine with true type fonts under 4.2.0, so this seems to be an issue with Mozilla.
Font issues, over to intl
Frank: This sounds like the bug 92590. I really think we should spend time looking at this as it may show up in may different ways.
I did some testing with my fonts directory and xfs and came to the conclusion the bug's gravity is proportional to the number of tt fonts that I have installed (btw, I have 190 tt fonts). There doesn't seem to be a specific group of fonts which cause this problem. Reducing the number of installed fonts to ~40 still made mozilla (and X) use a lot of RAM and swap, but not enough to make everything unresponsive. With all fonts installed, this is the output of ps before I killed mozilla: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 783 10.8 31.0 90956 39304 ? S 17:36 0:05 /usr/local/mozilla/mozilla-bin root 785 0.0 31.0 90956 39304 ? S 17:37 0:00 /usr/local/mozilla/mozilla-bin root 786 0.0 31.0 90956 39304 ? S 17:37 0:00 /usr/local/mozilla/mozilla-bin root 787 0.0 31.0 90956 39304 ? S 17:37 0:00 /usr/local/mozilla/mozilla-bin root 792 0.0 31.0 90956 39304 ? S 17:37 0:00 /usr/local/mozilla/mozilla-bin root 831 0.0 31.0 90956 39304 ? S 17:37 0:00 /usr/local/mozilla/mozilla-bin root 698 9.9 67.4 157272 85236 ? S<L 17:36 0:06 X :0
DOH! Can you tell if these mapped with an iso10646 encoding? (If so then this makes perfect sense. Does anyone else understand the problem?) Flavio: would you try doing an xlsfonts with/without the tt fonts and diff'ing to see how they are mapped.
Created attachment 68751 [details] xlsfonts diff (with/without tt fonts) Here's the diff, Brian. Practically all, if not all, mapped with an iso-10646 encoding.
I count 191 iso10646 fonts out of 1544 fonts listed in the diff. Still, this could easily explain the problem. Shanjian: is there a way you can help Flavio collect the information to tell what is happening?
Flavio: what is you default character set encoding? (under the menu: View->"Character Coding"->...)
Western (iso-8859-1), with autodetection off.
Reproduce on WinME, and base on comment #1, it's existing on Mac too. Conforming... and change the OS to all.
I do not understand why ylong change to all I think the problem is the "a lot of memory" problem. Does it also happen on window?
My understanding of what's happening is, In displaying a binary file as text, mozilla will surely meet some characters that its glyph is hard to find if it exists at all. That leads to traversing all system available fonts, include iso10646 encoded fonts. Each time we load such a font, we need to get XFontStruct with per char info. That is not only expensive in term of time, it also cause xfs and mozilla to allocate certain amount of resource. When the number of fonts being tried reaches certain limit, it will sufficiently bring the system down. Solution: 1. (Quick and Dirty) We limits the number of iso10646 fonts being tried in one glyph resolving session. This number can be controlled by a preference. In times when this problem is eliminated in a better way, we can just set the number to be infinite. 2.(For system using locale font server), we can cache the ccmap for system available fonts. Since this is a one time operation, we can sort the order of all ccmaps in term of subset/superset.(brian, is your locale database implementation for this purpose?) 3.Wait until a client side font solution is available. We will still suffer in certain degree just like mac/win, but it should be much better.
> That leads to traversing all system available fonts, include iso10646 > encoded fonts ... with per char info. Shanjian: I believe you are right. Before we implement a fix could we verify this by getting a listing of the fonts that are opened? Oops, the font debug code does not report this. Perhaps we should fix this. Humm. I'm not sure what we can do about this. If we don't try to find a glyph we will get complaints that we should do better. The quick and dirty solution is to do nothing which I don't like. We cannot reliably cache the list of glyphs in the iso10646 fonts since we have no way to tell if the list ever changes so we have no way to tell we should update the cache. Humm, I don't like this. Humm, I don't like this.
ylong- please try to reproduce this. [need more info]
Can anyone please test whether running the Xserver+fontserver with the option "-deferglyphs all" fixes the issue (e.g. % Xsun -deferglyphs all :0) ?
"-deferglyphs all" doesn't fix it.
Question is whether the Xfree86 code supports "-deferglyphs" or not. Does anyone know this ?
XFree does support -deferglyphs as a command line option or as a font server config option. Arguments are "all", "none" or "16".
Any X11R6.x Xserver should have this option. Question is whether the Xfree86 code really _implements_ it or if this is a "no-op"... ... if it does not solve the issue it may be a "no-op"... ;-(
I had a very similar issue in the client side TrueType code. Getting the list of valid chars could take *minutes* and could happen right in the middle of displaying a page (when searching for char/glyph). I added a bunch of code to build a font catalog to save the list of char/glyphs in each font. We could consider doing something like this for the X fonts. The problem is slightly different: for the TrueType fonts I can tell if the catalog is stale by checking if font file timestamps have changed. Using XListFonts we cannot tell if the underlaying fonts have changed. While this is very uncommon it can happen and over a long time users will experience problems if the catalog becomes stale. Perhaps (for local X access) we could get the X font path and check if the files have changed. My time is limited and I'm focusing on TrueType printing so I won't be working on this. If someone else wants to work on this I would be happy to talk with them.
nsbeta1- untill IQA reproduce this.
Yuying, do you have any updated test results on low end machine?
I couldn't reproduce it on one of Brian's linux which is kind of slow. John: Do you have any status one it? I remember that Jonathan Granrose asked you help to try it on your slow linux machine.
Come by and pick it up, it's in my cube.
I couldn't reproduce it on a few machines. Reporter: do you still has the problem on latast trunk build? doesn't it has to be some specified ttf fonts installed? thanks!
I still have the problem with the latest build. AFAIK it doesn't need any specific fonts (I've done some testing). X and Mozilla's memory usage is proportional to the number of tt fonts present. If I remove some of them Mozilla actually displays the file after some swapping. Do any of your tt fonts have an iso-10646 encoding?
16 years ago
*** Bug 142495 has been marked as a duplicate of this bug. ***
shanjian is no longer working on mozilla for 2 years and these bugs are still here. Mark them won't fix. If you want to reopen it, find a good owner first.
Mass Bug Re-Open of bugs Frank Tang Closed with no good reason. Spam is his fault not my own
Mass Re-assinging Frank Tangs old bugs that he closed won't fix and had to be re-open. Spam is his fault not my own