241223 - Mozilla 1.6 freezes with 100% CPU utilization on http://landsbank.fo/gz/unicode.html

Status: RESOLVED EXPIRED

(SeaMonkey :: General, defect)

Description

[David K]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

I went to http://landsbank.fo/gz/unicode.html with Mozilla 1.6.
Loading this page the browser froze and jumped to 100% CPU 
utilization, where it remained until I stopped it with the
task manager.
Internet Explorer 6.0.2800.1106 handles the page fine.

Reproducible: Always
Steps to Reproduce:
1.  Gp to http://landsbank.fo/gz/unicode.html
2.  Observe how the 1.6 browser freezes with 100% CPU
3.

Actual Results:  
Browser froze

Expected Results:  
Browser shouldn't have froze

Comment 1

[Magnus Melin [:mkmelin]]

Yep, locks up here too. Tried with 1.6 and 1.7b on linux.

Comment 2

[Christian Weyland]

On my system (1.7b/20040420, win2k) Mozilla is NOT freezing but completely
unresponsive for 1-3 minutes.
Additionaly, it consumes about 128 MB RAM.

Maybe, this bug is related to/dup of bug 116437.

The example URL is a tar/gzipped XML-document, btw.

Comment 3

[David Park]

It took 2-3 minutes to come up on build 2004042108. When I did it a second time
to did not come up at all. This is on Windows XP Pro.

Comment 4

[Boris Zbarsky [:bzbarsky]]

gzipped, sure.  But there's not one itty bit of tar involved.

The real issue here are all the unescaped things like "<control>", "<noBreak>",
ets scattered about the file.  These lead to a content tree that is O(N) in
depth; reflow on such a tree is very slow in Mozilla.

I did profile this, and the profile shows nothing unexpected -- a good chunk of
time taken looking for fonts, and just tons and tons of reflow happening.  Not
surprising.

We already have bugs both on the fact that broken markup like this produces deep
trees and on the fact that reflow on such trees is very slow.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Er, I was wrong.  There is in fact tar... which they claim is HTML.  The thing
inside the tarball is SO not XML, though (as soon as an XML parser hits the
</p>, it'll drop the whole thing and return a well-formedness error....

Comment 6

[Kenan]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040827

confirming the behavior: freezing for some minutes (Athlon 500: 20 min) and
allocation of memory of about 300MByte.
IE took 2-3 min to load the page.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Kenan, we know.

Comment 8

[Gervase Markham [:gerv]]

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 9

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.