Closed Bug 174359 Opened 22 years ago Closed 12 years ago

100% CPU use and browser halts on special JavaScript code

Categories

(Core :: DOM: Core & HTML, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: ksenux, Unassigned)

References

Details

(Keywords: perf)

Attachments

(1 file)

Browser halts with 100% CPU use on this script:
<html>
<body>
<SCRIPT LANGUAGE="JavaScript">
a=33;
b=1;
function colp() 
{
for(a;a<10000;a++)
 {
 document.write("<font size=2>",a,"</font>","-<font size=5
color=red>&#",a,"</font>",";&nbsp;&nbsp;&nbsp;"); 
 b=b+1;
 if (b>=12) {document.write("<br><hr><br>"); b=0;};
 }
}   
</SCRIPT>
<SCRIPT LANGUAGE="JavaScript">colp();</SCRIPT>
</body>
</html>
Confirming bug with Mozilla trunk binary 20020114xx on WinNT.
Reassigning to DOM Level 0 -

I stepped through this code via the JS Debugger, and the first
two characters got visibly document.written(): for |a| = 33, 34.
I had Mozilla side-by-side with the debugger, and I could actually
see the two characters in the browser window.

But no further document.writes were visible, even though I continued
to traverse the loop step-by-step.

I could "flush" the other characters by setting |a| to the upper bound,
10000. Then all the characters that had accumulated got document.written
at once - about 30 characters or so by the time I did that.

It just seems that Mozilla can't handle the load of document.writing
10,000 characters like this. IE6 handles it without any problem on my 
machine (WinNT4.0 (SP6), 500MHz CPU, 128 RAM). 
Assignee: rogerl → jst
Status: UNCONFIRMED → NEW
Component: JavaScript Engine → DOM Level 0
Ever confirmed: true
Keywords: perf
QA Contact: pschwartau → desale
Summary: 100% cpu use and browser halts on special JavaScript code → 100% CPU use and browser halts on special JavaScript code
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
This is essentially the same as the testcases in bug 23187 (and a jprof shows
the same issues).
Depends on: 145425
Except this jprof also shows two O(N^2) searches in nsBlockFrame::AppendChild
(because nsLineBox has to search for the last child and because it has to do
IndexOf() when we call AddFrames; perhaps we should have a way to indicate that
AddFrames is just appending?)
Blocks: 112858
I think slow AppendChilds are also encountered when pasting lots of lines of
text into editor.
No problems with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050903 Firefox/1.6a1 I think this is fixed.
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
marking WFM based comment 6 and my WFM

does this mean blocking bug 145425 (which bz set) is also WFM? :)
Status: NEW → RESOLVED
Closed: 19 years ago
QA Contact: desale → ian
Resolution: --- → WORKSFORME
You tell me.  This was blocking that bug because it covered a specific testcase that showed perf issues in a profiler.  Since you marked this worksforme I'm assuming you did some profiling and the issues are gone, right?
Not sure which you are suggesting I profile about but I did not do a profile on either. And I just realized my taskmgr was set at slow update, so perhaps my report is suspect. Still, cpu usage didn't go above 15%.  

What's a good profiler for windows?

Reopening.  I don't care what your CPU usage is; the question is whether actual profiling shows any issues in the code.  And on this testcase, it did last I checked and I don't recall the code being changed since.

http://www.mozilla.org/performance/tools.html#profiling has some profiling tools listed.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
this is my first profile. I followed instructions at http://www.hacksrus.com/~ginda/venkman/faq/venkman-faq.html#profiler
using venkman from http://getahead.ltd.uk/ajax/venkman

I have no skill to analyze or even say it is a good profile.
Assignee: general → nobody
QA Contact: ian → general
Wayne: This looks wfm, can you confirm ?
WFM 15.0a1 (2012-04-29)
Status: REOPENED → RESOLVED
Closed: 19 years ago12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: