Recursive JS function crashes Mozilla

RESOLVED INCOMPLETE

Status

()

--
critical
RESOLVED INCOMPLETE
16 years ago
10 years ago

People

(Reporter: cgranade, Assigned: cgranade)

Tracking

({crash})

Trunk
x86
Windows XP
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:dos], URL)

Attachments

(2 attachments)

(Assignee)

Description

16 years ago
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.

Comment 1

16 years ago
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
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

Comment 4

16 years ago
Created attachment 120142 [details]
WinNT stack traces (after interrupting page load)
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.
(Assignee)

Comment 6

16 years ago
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

Comment 8

15 years ago
dup of bug 77271?

Comment 9

15 years ago
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
Last Resolved: 15 years ago
Resolution: --- → FIXED
Whiteboard: [sg:dos]
(Assignee)

Comment 11

14 years ago
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

Comment 13

10 years ago
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).

Comment 14

10 years ago
Created attachment 360943 [details]
Activity Monitor sample from Camino
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
Last Resolved: 15 years ago10 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.