120238 - X font scaling : Mozilla is comsuming all the memory available when visiting a certain web page

Status: VERIFIED DUPLICATE of bug 150339

(Core :: Layout, defect)

Description

[Henrik Weckström]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20020115
BuildID:    2002011513

The abobe URL crashes my computer frequently. Both with RedHat 7.1 and 7.2 and
with different versions of mozilla (eg 0.9.7).

Something is eating all the memory on the computer and eventually if mozilla is
not killed (doesn't respond to mouse) the whole computer will crash.

I have no problems with Windows-builds.

  

Reproducible: Always
Steps to Reproduce:
1.Surf to the webpage
2.
3.

Actual Results:  Mozilla stops responding, computer starts swapping and gets
slowed down because of that. If Mozilla is killed, then everything is normal again.

Expected Results:  Viewed the webpage =)

Comment 1

[Erik Hensema]

It's not Mozilla eating all memory, it's the X-server. On my machine X grew to
at least 132 MB before I could terminate Mozilla. Mozilla only took about 30 MB
memory, which is normal.

Comment 2

[Erik Hensema]

Seems similar to bug 98158

Comment 3

[Diego Biurrun]

This is indeed the X server experiencing some big time memory leak, it grows to
more than 500MB memory usage on my machine in seconds.  Isn't this a bug in
xfree and should we somehow report it there?  I use 4.1.0-11 on an up to date
Debian testing.  What systems are you guys on?  What version of xfree?

I am taking a wild guess here and moving to component x-remote, please reassign
as necessary.

Comment 4

[GavinS]

Probably unrelated, but I find that the Xsun server on Solaris 2.6 gets bigger
and bigger when mozilla is running, but this happens very slowly, and I haven't
tied it down to specific sites. It used to be much worse, and I had to restart
the X server every few days, but it is much less often now.

Comment 5

[timeless]

not xremote.

Comment 6

[John Morrison]

In the included stylesheet, there is this rule:

strong { font-size: 140% }

and then in the HTML, there are multiple sections like:

<font FACE="Arial" SIZE="2"><strong>Pääkaupunkiseutu<strong></font><p>

If that single CSS rule is removed, then this bug is not present. (In fact, 
100% or 110% are OK, but 140% is not). 

So, anyways, this has to do with font-scaling on x-based systems.

Comment 7

[Christopher Blizzard (:blizzard)]

Might be an X bug.  It also might be that the scaling of the font takes up a lot
of memory.

Comment 8

[Diego Biurrun]

How much memory can this take?  I have 512MB RAM and the same amount of swap. 
Xfree eats it all up including swap before crashing..

Comment 9

[Christopher Blizzard (:blizzard)]

I don't know.  Sounds like an X bug of some kind.

Comment 10

[John Morrison]

It may well be an X bug, but I believe there are checks in place now so that we 
don't feed, e.g., font-size: 100pt;, into the X server (or xfs, whichever).

It appears that either this page is somehow bypassing those checks, or those
checks have been changed.

Note: when I attempted to quit X, I had a hard crash of Linux. 

Comment 11

[kill this account]

When I set NS_FONT_DEBUG=3D I see it asking xfs for fonts at about 100x larger 
than reasonable (eg: 1621 pixel, 1158 pixel, ...) which looks like bug 92590.

Then I see it seeming to be in an infinite loop looking for a font
(eg: FindFont(a/0x0061))

Then (a long time later) the page comes up.

Comment 12

[Frank Tang]

reassign to shanjian. shanjian- please chat with bstell
do we have a dup of this ?
we need to find out why it ask the wrong (very big) size. do we have
miscaculation of size or some code trash the stack ????

Comment 13

[Erik Hensema]

The page renderes fine in both Netscape 4.7x and Konqueror. I'm using
antialiased truetype fonts, by the way.

GanviS: do you experience this bug using Xsun?

Can anybody else running a server other than XFree test this please? XFree86 4.2
is also not tested yet, AFAIK.

Comment 14

[Shanjian Li]

The problem seems caused by statement like this,
"<strong><strong><strong><strong><strong><strong><strong><strong><strong><strong
>
<strong><strong>                        <font face="Arial" size="2"><strong>Lapp
i<strong></strong></strong></font></strong></strong></strong></strong></strong><
/strong></strong></strong></strong></strong></strong></strong></p><p>^M
<strong><strong><strong><strong><strong><strong><strong><strong><strong><strong>
<strong><strong><strong><strong>                        </strong></strong></stro
ng></strong></strong></strong></strong></strong></strong></strong></strong></str
ong></strong></strong>"

Continuous <strong> tag leads to very big font size, but the newly created font 
does not really render anything. "<font face="Arial" size="2">" override the 
font specification before displayed text. The nature of X scale font exaggerate 
the problem. The webmaster of this page really need to change this practice.

Does anybody has a strong opinion why this must be fixed? if not, I will mark it 
wontfix. 
 

Comment 15

[Christopher Aillon (sabbatical, not receiving bugmail)]

Yes, I do have a strong opinion why this must be fixed.  If some jerk decides to
make a page with the code you just outlined, they could easily put it on a
website and advertise it as a "Mozilla exploit".  Or someone could legitimately
make a page as such without realizing this, and cause Mozilla to crash X.

In either case, this leads to dataloss in any application which is open in X. 
It could be it a long e-mail, a bugzilla bug report, a StarOffice document by a
reporter on how great Mozilla is (which would be lost and promptly replaced by
an article on how much Mozilla sucks), etc.  We should catch this and prevent it
from happening.  Feel free to open a _separate_ bug for evangelizing the site to
use better code, but there is no reason we should leave this unfixed, IMHO.  Yes
it is rare, but is easy to reproduce and easy to exploit.

Microsoft gets flak all the time for having bugs that make the OS crash.  This
is up on par with one of those because for all intensive purposes, the X server
_is_ the OS to many *nix users.  Please fix this.

Comment 16

[Diego Biurrun]

If you want a strong opinion, here is one:

This is the worst bug I have seen in Mozilla to this day.  Period.  We are not
only crashing but taking our whole environment down...  How can it get any worse?

Please fix this, the sooner the better.

Comment 17

[John Morrison]

Er, what they said (above).

And, I'm confused by the comment about "<strong><strong><strong>...". That 
fragment does not appear in the URL for this bug. 

Earlier, I had noted that this was tied to the presence of a 'font-size: 140%'
in the linked css for this page. Without that rule, there is no problem. 

Try these two testcases (inside firewall, but really just the same content as 
the original URL, with the 'ok' case missing the 140% rule).

http://jrgm.mcom.com/bugs/120238/ok.html
http://jrgm.mcom.com/bugs/120238/bad.html

Comment 18

[Shanjian Li]

Attachment: locally saved page using mozilla

Comment 19

[Shanjian Li]

I posted my locally saved copy using mozilla. This is different from the copy I 
see using Netscape4.x. It might because that is a asp page. 

There is one thing I am not absolute sure. That is if we need to render a space
char or not. If we readlly don't need to render anything, and thus we don't need
any font metrics for such a font, delay font's realization might solve the problem. 
Otherwise our options to solve the problem is very limited.  

Comment 20

[Arthur]

Could this be caused by the XFree86 bug described in
http://sdb.suse.de/en/sdb/html/pohletz_x11_consuming_mem.html ?
This is fixed in the 4.2.0 version. It would nonetheless be nice not to trigger
that bug in pre-4.2.0 versions.

Comment 21

[Shanjian Li]

*** Bug 90547 has been marked as a duplicate of this bug. ***

Comment 22

[Lars Hugentobler]

just in case the xfree 4.2.0 confirmation is still needed: the mentioned url
works for me with xfree86-4.2.0 (compiled from a redhat rawhide srpm), kde-2.2.2
and mozilla-linux-2002031008. memory consumption is normal.

Comment 23

[Jesse Ruderman]

Might be a dup of bug 150339.

Comment 24

[Diego Biurrun]

This bug is older, but bug 150339 has a patch, so this one will have to go...

*** This bug has been marked as a duplicate of 150339 ***

Comment 25

[Diego Biurrun]

The problem is gone so I suppose it is safe to mark this VERIFIED, the bug this
was duped against is also VERIFIED.