288396 - Endless loop writing to a Form hangs Firefox

Status: RESOLVED WORKSFORME

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

Description

[Jeff F.]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

I had a hard time classifing this because critical seemed to small, when you
load this code it will create an endless loop that will continue to write to a
small text box. This causes my computer to crash, not JUST fx, but Windows. The
Blue screen of Death occers, note: this is driver spacific but it will always
cause fx to not respond. A cap should be placed on both mem and repatition to
fix this.

Reproducible: Always

Steps to Reproduce:
1.Go to my attatchment
2.press go


Actual Results:  
on MY computer, Blue screen of Death.

Expected Results:  
I wanted it to burn out my Hard Drive and cause my computer to catch fire. j/k

The device driver(ialmrns) got stuck in an infinate loop.

Comment 1

[Jeff F.]

Attachment: Problematic code, will cause fx to stop responding, may crash Win.

Comment 2

[Matthias Versen [:Matti]]

The BSOD is a problem with your system, not a Firefox one.
I but I can confirm that Mozilla hangs

Comment 3

[Jeff F.]

(In reply to comment #2)
> The BSOD is a problem with your system, not a Firefox one.
> I but I can confirm that Mozilla hangs

Right, the BSoD is Driver dependant, but I have been able to reproduce it in 2
of 12 comps it was tested on.. the 2 had dif. drivers too.

Comment 4

[Boris Zbarsky [:bzbarsky]]

So this is interesting.  I'm guessing that the dom branch callback limit just
isn't hit until we've been doing this for a while, since there's very little JS
here and lots of waiting on the native code...

Comment 5

[Boris Zbarsky [:bzbarsky]]

Did some testing, at timeless's suggestion.  We kill off the recursion at a
depth of 1000 or so in current builds.  That takes about 75 seconds to get to on
my machine on that testcase.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Hmm.. what are we failing at here? it just seems like a normal js recursion and
a lot of setting .value on an <input>. Neither of these things should cause
problems, even though the value-string might be a bit long I guess.

Or are we running out of stackspace?

Comment 7

[Boris Zbarsky [:bzbarsky]]

> Or are we running out of stackspace?

When we kill off the recursion, yes.

The real failure is that we completely freeze up the browser for over a minute
instead of popping up our nice "this script is running too long" dialog... ;)

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

So it sounds like there's two separate issues here:

1. JS-recursion is allowed to run so far that we run out of stackspace and crash
2. When performing heavy js for too long we don't pop up a warning letting the
   user abort.

Or are they related somehow?

Comment 9

[Boris Zbarsky [:bzbarsky]]

> 1. JS-recursion is allowed to run so far that we run out of stackspace and
> crash

In a current build on Linux, that is not the case.  It runs till it hits the
stack size limit we set on the JSEng, then it's killed.  No crash.

> 2. When performing heavy js for too long we don't pop up a warning letting the
>    user abort.

More precisely, when performing very time-consuming operations that look like
single statements to JS...

Comment 10

[Hixie (not reading bugmail)]

Didn't we recently switch to using wall-clock timing for JS run time?

Comment 11

[Boris Zbarsky [:bzbarsky]]

We did, but checking the wall-clock time is a pretty expensive operation, so we
do it only so often, in numbers of JS statements.  In particular, we first check
the time at 256 iterations of a loop or whatever it is that triggers the branch
callback, and check it at 4096-iteration intervals thereafter...

Comment 12

[Jeff F.]

Attachment: Crashing code alone.

Majorly cleaned up the code, only the problem is here now with several of my
tests.

Comment 13

[Jeff F.]

Still an issue with lateset build of DeerPark Alpha 2

Comment 14

[Jeff F.]

Just looking at an old bug. 
All infinite recession is now fixed with either allocation size overflow or script timeout.