starts swapping violently when the URL is visited

RESOLVED WORKSFORME

Status

()

Core
Internationalization
--
critical
RESOLVED WORKSFORME
16 years ago
11 years ago

People

(Reporter: Flavio Ribeiro, Unassigned)

Tracking

({intl})

Trunk
All
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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.

Comment 1

16 years ago
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?
(Reporter)

Comment 3

16 years ago
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?
(Reporter)

Comment 4

16 years ago
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

Comment 6

16 years ago
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.
(Reporter)

Comment 7

16 years ago
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

Comment 8

16 years ago
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.

(Reporter)

Comment 9

16 years ago
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.

Comment 10

16 years ago
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?

Comment 11

16 years ago
Flavio: what is you default character set encoding?

(under the menu: View->"Character Coding"->...)
(Reporter)

Comment 12

16 years ago
Western (iso-8859-1), with autodetection off.

Updated

16 years ago
Keywords: intl
QA Contact: ruixu → ylong

Comment 13

16 years ago
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

Comment 14

16 years ago
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

Comment 15

16 years ago
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

Comment 16

16 years ago
> 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.

Comment 17

16 years ago
-> nsbeta1
Keywords: nsbeta1

Comment 18

16 years ago
ylong- please try to reproduce this. [need more info]

Comment 19

16 years ago
Can anyone please test whether running the Xserver+fontserver with the option 
"-deferglyphs all" fixes the issue (e.g. % Xsun -deferglyphs all :0) ?
(Reporter)

Comment 20

16 years ago
"-deferglyphs all" doesn't fix it.

Comment 21

16 years ago
Question is whether the Xfree86 code supports "-deferglyphs" or not. Does anyone
know this ?
(Reporter)

Comment 22

16 years ago
XFree does support -deferglyphs as a command line option or as a font server
config option. Arguments are "all", "none" or "16".

Comment 23

16 years ago
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"... ;-(

Comment 24

16 years ago
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.

Comment 25

16 years ago
nsbeta1- untill IQA reproduce this. 
Keywords: nsbeta1 → nsbeta1-

Comment 26

16 years ago
Yuying, do you have any updated test results on low end machine?

Comment 27

16 years ago
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.  

Comment 28

16 years ago
Come by and pick it up, it's in my cube.

Comment 29

16 years ago
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!
(Reporter)

Comment 30

16 years ago
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

Comment 31

16 years ago
*** Bug 142495 has been marked as a duplicate of this bug. ***

Comment 32

13 years ago
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
Last Resolved: 13 years ago
Resolution: --- → WONTFIX

Comment 33

13 years ago
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 → ---

Comment 34

13 years ago
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
(Reporter)

Updated

11 years ago
Status: NEW → RESOLVED
Last Resolved: 13 years ago11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.