142206 - http://www.thai.net/navigate/ sends CPU to 100%

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[David Gerard]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2)
Gecko/20020503
BuildID:    2002050306 (1.0 branch)

http://www.thai.net/navigate/ (a Thai page for Netscape and Mozilla)
sends CPU to 100% for me and never seems to come back. Mozilla locks up
utterly and I can't do anything else with it until I kill it.

The page loads fine in IE 5.5 and Opera 6 of course :-)

Note that the page does not even load in Mozilla before the 100% CPU
thing happens.

Reproducible: Always
Steps to Reproduce:
1. Go to http://www.thai.net/navigate/

Actual Results:  Mozilla hangs taking 100% of CPU, before even displaying the page

Expected Results:  Displayed the page and not hung

I have the (Win2000) Thai language pack installed on this box.

Comment 1

[Rainer Bielefeld]

No CPU-load-problem with
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0+) Gecko/20020503

But:
2 pictures at the end of the page 
http://www.thai.net/navigate/image/link_tlwg.gif and 1 other
will not be loaded 
works with-image-URI in separate TAB ina in IE6

Comment 2

[David Gerard]

Still getting the error. To be precise, it loads enough data to display the
page title before going into 100% CPU.

We are using the same build, but me on an NT and you on a 9x Windows. Hmm.
Anyone else out there?

I had a quick look at the source but couldn't see anything dodgy.
http://validator.w3.org/ is not entirely happy with it.

Comment 3

[Dave T]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc2) Gecko/20020502
buildID=2002050206
I can confirm this sending CPU to ~100% on acessing this web site on win98
original edition.
Can not get the window to close, nor can I get the taskbar to popup the context
menu for close. Ctrl-Alt-Del-> end task, successfully kills it, leaving me with
only 70/70 system resources.
The site does not appear within 1 minute.

Comment 4

[Matthias Versen [:Matti]]

confirming with win2k build 20020503..

-> Layout

I get many assertions:
###!!! ASSERTION: failed to find segment: 'lastSegment < textRun.mNumSegments',
file ../../../../../layout/html/base/src/nsTextFrame.cpp, line 4901
WARNING: bad starting offset, file ../../../../../layout/html/base/src/nsTextTra
nsformer.cpp, line 215
###!!! ASSERTION: redo line on totally empty line: 'aState.IsImpactedByFloater()
', file ../../../../../layout/html/base/src/nsBlockFrame.cpp, line 3514
###!!! ASSERTION: unconstrained height on totally empty line: 'NS_UNCONSTRAINEDS
IZE != aState.mAvailSpaceRect.height', file ../../../../../layout/html/base/src/
nsBlockFrame.cpp, line 3516
WARNING: bad starting offset, file ../../../../../layout/html/base/src/nsTextTra
nsformer.cpp, line 215
###!!! ASSERTION: redo line on totally empty line: 'aState.IsImpactedByFloater()
', file ../../../../../layout/html/base/src/nsBlockFrame.cpp, line 3514
###!!! ASSERTION: unconstrained height on totally empty line: 'NS_UNCONSTRAINEDS
IZE != aState.mAvailSpaceRect.height', file ../../../../../layout/html/base/src/
nsBlockFrame.cpp, line 3516
WARNING: bad starting offset, file ../../../../../layout/html/base/src/nsTextTra
nsformer.cpp, line 215
###!!! ASSERTION: redo line on totally empty line: 'aState.IsImpactedByFloater()
', file ../../../../../layout/html/base/src/nsBlockFrame.cpp, line 3514
###!!! ASSERTION: unconstrained height on totally empty line: 'NS_UNCONSTRAINEDS
IZE != aState.mAvailSpaceRect.height', file ../../../../../layout/html/base/src/
nsBlockFrame.cpp, line 3516
WARNING: bad starting offset, file ../../../../../layout/html/base/src/nsTextTra
nsformer.cpp, line 215

Comment 5

[David Pilcher]

WFM 2002050206 Windows 2000, page loads correctly, no high CPU use

Comment 6

[Dave T]

I spent some time trying to build a reduced test case, by first saving the site
using ie 5.01, and then fixing the html errors. It continues to crash until I
changed the line from x2= to src=(near the bottom of the source):

<SCRIPT language=javascript1.1>

x2="<IMG WIDTH=0 HEIGHT=0 SRC='http://truehits.gits.net.th/gengif.php3?hc=00000043";

</SCRIPT>

It would then load properly, although the page hit counting site that this site
connects to must be extremely slow. Page takes 40 secs to finish, even though it
has otherwise retrieved all images on the page.

(is it OK to set an image size of 0,0; i am not too familiar with this ?)

At this point I decided to start with the original file again. At this time (I
think) I chose to install netscape 4.76 to retrieve the file again. The first
web site file save had been using internet explorer, and was Web page complete,
which modifies the original file to point locally.
However, from this time on, I have always been able to get the site to display
normally. ~:/

Even the original file stored on my local disk is displayed normally (that is
the original downloaded one), which earlier was locking Mozilla up requiring a
3fs, end task.
I have now tried uninstalling netscape 4.76, but am not able to reproduce the
problem.

Comment 7

[Isriya Paireepairit]

Dear,
I run www.thai.net/navigate
and I can't access www.thai.net at the moment.
(maybe www.thai.net host problem).

If I can access it, I'll try to remove counter and test it again.
but I don't find this problem on 1.0RC1 (2002041711)
on Windows98

Comment 8

[Dave T]

While I can still succesfully load the URL in the browser, if I go File|Edit
Page, that is in Mozila Composer, I get the same CPU 100% problem, and the page
is never displayed.

Saved the original page using mozilla. This file opened normally in composer.
Saved original page as web page complete. This file would not open in composer.

After cleaning the html 4.0 validation errors, got to this validation error:
W3C  HTML Validation Service Results

Jump to: Outline, Source Listing or Parse Tree.
File: mozsave3.htm
Detected Character Encoding: tis-620
Select Character Encoding:
Options: Show Source Outline Parse Tree ...no attributes
 
Sorry, I am unable to validate this document because on lines 55, 99, 101 it
contained some byte(s) that I cannot interpret as tis-620. Please check both the
content of the file and the character encoding indication.
Valid HTML 4.01!
including the validator:

I worked out that the byte in question was $A0. I do not have experience with
other language charsets, so I don't know if this is correct -> someone with some
experience in this area may be able to say.

So at this point, the page happily verifies as w3c html4.01.
Composer load fails still.

I then worked through the body text, commenting out text (the thai text) until
at about 3/4 through the file, it was able to open in composer.

By working back a bit, I found the another char that composer does not like:
char $A2, which looks like a cent sign (in english wordpad). I search/replaced
each A2 with <!-- A2 --> comment. Composer opens succesfully.

I have checked this again by going to the original complete download file,
proving that composer fails to open, then fixing the A2 using comments, and can
now successfully open the file in composer.

It's possible this was the cause of the original browser problem ? 
Where do charset problems get keyworded ? intl ? l12y ?

Comment 9

[Isriya Paireepairit]

To Dave

1.) from your quote about HTML Validator problem.
I just test on my system (Win98 Thai/1.0Rc1)
with Wordpad (thai font display and no wrap line)  and I found that

line 55 : style="font-weight: bold">Latest&nbsp;Browser</span></td>
line 99  : <a href="history.html">Mozilla&nbsp;History</a><br>
line 101 :<a href="feature.html">Mozilla&nbsp;Feature</a><br>

same character in these lines is '&nbsp;' (non-breaking space).
but I think it is HTML Validator issue only, not this bug.

[e-mail] told me that this character (&nbsp;) isn't in tis-620
character set so HTML Validator found it.

2.) I just removed Truhits Counter out from original page (index.html)
and moved the problem (original) to http://www.thai.net/navigate/index-old.html
(attached to bugzilla too)

3.) For the character '$A2'.
[e-mail] told me that '$A2' mean 'Kho Khai' (2nd Thai Alphabeth)
in tis-620 encoding. But on Unicode/Latin1 it is cent sign.

I also attach 'Kho Khai' image displayed on www.thai.net/navigate too.
See Red Circle in Attachment.

4.) In Attachment, There's also another Character problem (Tho Taharn) with
Bug#117484. (http://bugzilla.mozilla.org/show_bug.cgi?id=117484)
I mark it with Blue Circle.
Not related with this bug.

Comment 10

[Isriya Paireepairit]

Attachment: Screen Capture with '$A2 ' character

Comment 11

[Isriya Paireepairit]

Attachment: Original HTML from URL

Comment 12

[David Gerard]

changing URL field from http://www.thai.net/navigate/ to
http://www.thai.net/navigate/index-old.html .

It would be nice if Mozilla didn't die on a Mozilla advocacy page :-)

Is anyone seeing this on an OS other than Windows, by the way?

Comment 13

[Dave T]

Attachment: minimum html testcase based on Isriya original web page

I have taken a different route to creating a testcase minimized html file that
still causes composer to go to CPU 100%.

Kept cutting out code from the original source file, until composer can open
it.
As I got close, I additionally see a vertical cursor line at the top of the
composer document body, but still no document (although the title is placed,
and the Document: done is being displayed at the bottom.)

The attachment is the minimum text that can be in the file before composer can
actually open it.

Note that any one of the following mods will allow the file to be opened:
removing the meta css line
removing the charset line
removing one <B> </B> from around some text.
removing the <ul><li> </ul> </li> around the text.
removing the first or second row of the table.
removing the blockquote start and finish.

It seems that something is running out of resources (fonts) since changing
anything to do with the text seems to cause the problem to appear.?

Note that I don't haave a Thai font installed (as far as I know), so I assume
mozilla is generating the correct characters on screen, at least they look as
if they might be Thai characters.

Note that this attachment is w3c valid 4.01 transitional.
Also, generating some errors in the html coding eg. leaving off > etc. allows
composer to open the page normally. (like it only likes invalid html ;)

I think this is the reason why save page only, and then edit in composer works
(ie the original file does not have </li>, and some weird </span> positions, ie
html errors. 
But when save web page complete is done the browser fixes the html faults
first, as well as modifying linked file locations. This ensures the complete
file is (nearly) valid and hence composer opens it ok.
(i think) It incorrectly writes what was 
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> as
<!DOCTYPE doctype PUBLIC "-//w3c//dtd html 4.0 transitional//en">
	  ^
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc2) Gecko/20020502

Comment 14

[Isriya Paireepairit]

>(i think) It incorrectly writes what was 
><!doctype html public "-//w3c//dtd html 4.0 transitional//en"> as
><!DOCTYPE doctype PUBLIC "-//w3c//dtd html 4.0 transitional//en">

All pages in my site were created by Allaire HomeSite 4.5 (Now, macromedia).
So !doctype tag is automatically added by Homesite.

What is the correct one 
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> or
<!DOCTYPE doctype PUBLIC "-//w3c//dtd html 4.0 transitional//en">

in the original page it was the first one.

Comment 15

[Simon Montagu :smontagu]

Marc, would you like to assign this to me? I've seen infinite loops similar to
the one described in comment 4 while debugging other hangs (e.g bug 95228 and
bug 129847) It appears that the assertion

###!!! ASSERTION: failed to find segment: 'lastSegment < textRun.mNumSegments',
file ../../../../../layout/html/base/src/nsTextFrame.cpp, line 4901

is always the prelude to an infinite loop in 
 |while (LINE_REFLOW_REDO == lineReflowStatus) {...}| 
in nsBlockFrame::ReflowInlineFrames

Comment 16

[Mason]

The HTML validator is fairly irascible about the DOCTYPE declaration.
http://validator.w3.org/

Specifically, the quoted text must not be altered:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

One could declare:
<!DoCtYpE htmL PubLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

But the validator will complain if the quoted text is altered:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 transitional//EN">
(a lowercase 't' instead of an uppercase 'T' in transitional)

Comment 17

[Kevin McCluskey (gone)]

Reassigning to Simon based on comment #15. Thanks for taking this Simon :)

Comment 18

[Simon Montagu :smontagu]

I discovered that I can eliminate the hang by going to Edit | Preferences |
Fonts and selecting Arial Unicode MS for Thai, as opposed to Bitstream Cyberbit.
Tentatively, I suggest that the bug is caused by inaccurate data in the font.
More investigation is needed.

Comment 19

[Frank Tang]

could this caused by the same problem in 142562? shanjian land the patch for
142562 into trunk 2002-05-24 16:04, if this problem cannot be reproduced on
trunk after that time but could be reproduced before it, then it could be the
same problem  

Comment 20

[Frank Tang]

simon- remember to log your progress on it. 

Comment 21

[Frank Tang]

roy- try to help simon about this.

Comment 22

[Roy Yokoyama]

CPU usage related.  cc momoi and bstell.   

Comment 23

[Roy Yokoyama]

I can't reproduce this on my Win2K-Ja with 
Netscape 7 PR1 (Gecko/20020603 Netscape/7.0b)

Comment 24

[Roy Yokoyama]

I can't reproduce it with today's build either.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a) Gecko/20020612

Comment 25

[kill this account]

WFM on my win2k system using moz-2002061206, ns-7.0PR1, 

Comment 26

[Frank Tang]

I can reproduce this on my winxp sc system with n7pr1. Not sure about the latest
build. reassign to yokoyama to investigate. 

Comment 27

[Roy Yokoyama]

>my winxp sc system with n7pr1.
well, I can't reproduce this on my WinXP-SC with NS7 PR1 nor
with 20020524-trunk (bit old).

frank, can you debug in your WinXP-SC machine?  I can't help you here.
assigning to ftang.

shanjian: can you try on your machine as well?
try
http://bugzilla.mozilla.org/attachment.cgi?id=82393&action=view
or 
http://www.thai.net/navigate/index-old.html

Comment 28

[Simon Montagu :smontagu]

I have started seeing a similar hang with the same assertions at
http://linux4arab.com, sometimes on initial page load and sometimes after
following a link and pressing the Back button.

Comment 29

[Frank Tang]

reassign to shanjian

Comment 30

[Shanjian Li]

I could not reproduce the problem with the minimal test case, but I did see the
problem  with the url :
http://bugzilla.mozilla.org/attachment.cgi?id=82393&action=view

Inside debugger, in nsTextFrame, around line 4918, numCharsFit == 73, while 
textRun.mTotalNumChars == 72. (Does it look familiar to you, rbs?)
It seems we still have some problem with GetTextDimensions. Anyway, I change my
code (see the patch), and the problem is gone. I could not see any problem even
after I backed out my change. That's weird. 

rbs, can you give a try? 

Comment 31

[Shanjian Li]

Attachment: test patch

Comment 32

[Simon Montagu :smontagu]

http://www.unicode.org/iuc/iuc10/x-utf8.html has been hanging for me in recent
optimized builds and asserting and then crashing (as in comment 4) in recent
debug builds.

Applying attachment 97248 [details] [diff] [review] solves the problem.

Comment 33

[rbs]

Attachment: real fix for the root cause

Comment 34

[Shanjian Li]

reassign to rbs.

Comment 35

[rbs]

Attachment: combined patch

Taking the other patch too... Robustness/safeguard are good.

Comment 36

[Shanjian Li]

Comment on attachment 97713 [details] [diff] [review]
real fix for the root cause

Looks reasonable. r=shanjian,

Comment 37

[rbs]

[For those who get WFM -- the bug is a combination of the window (i.e., the
available size which determines the text that fits) and the metrics of fonts
that happen to be picked.]

Cc:ing dbaron for sr.

Comment 38

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 97714 [details] [diff] [review]
combined patch

sr=dbaron.  Hopefully compilers will optimize the PR_MIN correctly (I suspect
so).

It might be good to add an assertion here:

> +    if (numCharsFit >= textRun.mTotalNumChars) { // fast path, normal case
>        lastSegment = textRun.mNumSegments - 1;

that the two numbers are equal, if it's something that's never supposed to
happen.

Comment 39

[rbs]

Attachment: add assertion

A debug radar that was firing when vising the problematic pages.

#ifdef DEBUG_rbs
  NS_ASSERTION(allDone || start == i, "internal error");
  NS_ASSERTION(allDone || data->mNumCharsFit != numCharsFit, "internal error");

#endif /* DEBUG_rbs */

The measuring code (the one with break indices) was overshooting in the even
where "font-switching" was happening in-between the last word. Intl users are
the ones that are going to be vulnerable to the faulty codepath, so suggesting
to backport the fix to all branches that are being used for end-user releases.

Comment 40

[Asa Dotzler [:asa]]

Comment on attachment 97831 [details] [diff] [review]
add assertion

a=asa (on behalf of drivers) for checkin to 1.2a

Comment 41

[rbs]

Fixed on the trunk.

Comment 42

[rbs]

shanjian, mind migrating the fix to those m1.0.x branches since you have them?

Comment 43

[Jaime Rodriguez, Jr.]

This looks like something good to get on the 1.0 branch. Nominating ...

Comment 44

[Randell Jesup [:jesup] (needinfo me)]

a=[e-mail] for 1.0 branch; please change mozilla1.0.2+ to fixed1.0.2
when checked in.  Please check in ASAP to make the 1.0.2 cut.

Comment 45

[Jaime Rodriguez, Jr.]

petersen: chris can we verify this as fixed on the trunk before we take it on
the branch?

Comment 46

[Chris Petersen]

Verified fixed on Mac OS X (2002-09-10-08) and Windows ME (2002-09-10-08).

Comment 47

[Chris Petersen]

Forget to mention they were TRUNK builds.

Comment 48

[rbs]

shanjian, are we done with this one (comment #42)?