Closed Bug 124464 Opened 23 years ago Closed 18 years ago

starts swapping violently when the URL is visited

Categories

(Core :: Internationalization, defect)

Product:
Core
Component:
Internationalization
Platform:
All
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: fr, Unassigned)

References

(
URL
)

Details

(Keywords: intl)

Attachments

(1 file)

xlsfonts diff (with/without tt fonts)
96.03 KB, text/plain
Details 
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
Assignee: law → yokoyama
Component: File Handling → Internationalization
QA Contact: sairuh → ruixu
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.


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.
Keywords: intl
QA Contact: ruixu → ylong
Reproduce on WinME, and base on comment #1, it's existing on Mac too.

Conforming... and change the OS to all.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → 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?
Assignee: yokoyama → shanjian
OS: All → Linux
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.
Status: NEW → ASSIGNED
> 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.
-> nsbeta1
Keywords: nsbeta1
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.
Keywords: nsbeta1 → nsbeta1-
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?
Blocks: 142495
*** 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.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
Mass Bug Re-Open of bugs Frank Tang Closed with no good reason. Spam is his
fault not my own
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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
Assignee: shanjian → nobody
Status: REOPENED → NEW
Status: NEW → RESOLVED
Closed: 19 years ago → 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: