Closed Bug 201552 Opened 21 years ago Closed 15 years ago

Recursive JS function crashes Mozilla

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: cgranade, Assigned: cgranade)

References

(
URL
)

Details

(Keywords: crash, Whiteboard: [sg:dos])

Attachments

(2 files)

WinNT stack traces (after interrupting page load)
64.61 KB, text/plain
Details
Activity Monitor sample from Camino
80.75 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312

The page described by the above URL contains an infinitely recursing JavaScript
function. As the call stack grows, the browser's procssor time allocation is
dedicated to the errant function, causing Mozilla to enter into a state that can
only be repaired by a forceful termination of mozilla.exe.
The errant function has a small piece of code that also resets the apparent size
of the call stack (while not actually doing so) so that Mozilla's JS engine
doesn't throw an Out of Stack Space exception.

Reproducible: Always

Steps to Reproduce:
Visit a page with the errant function.

Actual Results:  
Mozilla's current browser window begins to blink as the redraw callback to the
OS loses its processor time to the execution of the errant function. As earlier
described, all Mozilla windows must be forcefully killed to resolve the issue.

Expected Results:  
1. Seperated the proccesses which drive the different windows so that the crash
would not have been as catastrophic.
2. Detected a recursive JS function without a termination clause and thrown a JS
exception (I know... that's hard).
3. Properly traced the current stack size, and thrown an Out of Stack Space
Exception.
4. Choked the JS engine's resource allocation allowing for a graceful
termination of the affected browser window.
Here is the function in question:

<script>
function crashme ()
{
  var url = document.location;

  if (document.images)
    location.replace(url);
  else
    location.href = url;
 
  crashme();
}
</script>

<body onLoad="crashme ()">


The JS Engine already has checks for too much recursion,
as shown in this session from the standalone JS shell:

js> function f() {f();}
js> f();
1: InternalError: too much recursion


Therefore I believe this is a DOM or Security bug. Compare bug 185945:
"recursive document.write prevents browser from shutting down completely"

Reassigning to DOM Level 0, and cc'ing Mitch, Georgi -
Assignee: rogerl → dom_bugs
URL: http://www.monkeys.com/break-ie.htm → http://www.monkeys.com/break-ie.html
Status: UNCONFIRMED → NEW
Component: JavaScript Engine → DOM Level 0
Ever confirmed: true
Keywords: crash
QA Contact: pschwartau → ashishbhatt
Summary: Possible Exploit in MSIE Also Affects Mozilla → Recursive JS function crashes Mozilla
Johnny, Brendan, how straightforward will this be to fix? Will the fix be in the
engine?
Stack, please.

/be
I don't think this bug needs to be security sensitive. If I hear no objections
in a couple of days I am going to open this to the public.
I apologize if the Security Sensitive catagorization was in error. I simply saw
that this could be an opp to crash a system through less knowlegeable users.
Opening to public. Crash bugs are typically not security issues themselves,
although some security bugs manifest themselves as crashes in some cases (buffer
overflow is a typical example).
Group: security
Depends on: 220408
dup of bug 77271?
I see this on

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040330
Microsoft Windows 2000 Pro 5.00.2195 SP4
Fixed by bug 220408.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Whiteboard: [sg:dos]
Seems to break Firefox now. Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Chris, please file a new bug or cite talkback or a stack in a debugger showing
that you are seeing the same crash.  "Seems to break Firefox now" could mean
anything.

/be
Assignee: general → cgranade
Status: REOPENED → NEW
When opening above URL in a tab in Camino, one can recover by closing the tab.  However, Camino seems slow.  Attaching sample from Activity Monitor while visiting page in bug URL.

Tested with intel Mac running Mac OS X 10.4.11 with all current updates, and Camino nightly version 2.0b2pre (1.9.0.7pre 2009020512).
Kurt, don't find old bugs that sound vaguely like something you're observing and add to them. In any case, a crash is not a slow-down. File a new bug.

Marking this old bug INCOMPLETE. It was probably fixed.

/be
Status: NEW → RESOLVED
Closed: 20 years ago → 15 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: