298795 - Crash in javascript Array.toString with deep hierarchy

Status: VERIFIED WORKSFORME

(Firefox :: General, defect)

Description

[Oliver Hunt]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

An extremely deep hierarchy of arrays eg. [1, [2, [...]]] causes firefox to
crash and burn, a similar abuse of javascript can cause firefox's javascript
interpreter to consume a large number of system resources, effectively halting
the system

Reproducible: Always

Steps to Reproduce:
The following code triggers the fault:
  var elem=[0];
  for(var i=1; i<=10000; i++)
  {
    var ary=[elem, i];
    elem=ary;
  }
  document.write(elem);
Actual Results:  
As above firefox crashed

Expected Results:  
Anything but crash, the ECMA standard is somewhat ambiguous as to what we do if
an exception is encountered while processing Array.toString and one would
imagine that the above code would cause a stackoverflow error

Comment 1

[Oliver Hunt]

Attachment: Testcase that triggers the bug -- may cause firefox to crash

Comment 2

[Ria Klaassen (not reading all bugmail)]

Using WinXP I get a crash in 1.0.4 (TB6987778Q), but not in trunk.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050625
Firefox/1.0+ ID:2005062519

Comment 3

[Matthias Versen [:Matti]]

I see the crash in FF 1.0.4 but not in 
Mozilla/5.0 (Windows; U; Windows NT 5.2; de-DE; rv:1.8b2) Gecko/20050617

marking wfm
Please reopen if you can reproduce this in a Firefox trunk build or in the Deer
Park Alpha.

Comment 4

[timeless]

2005-06-27 02:48:10.951 Camino[14376] JS error: [JavaScript Error: "uncaught
exception: [Exception... "Component returned failure code: 0x8007000e
(NS_ERROR_OUT_OF_MEMORY) [nsIDOMNSHTMLDocument.write]"  nsresult: "0x8007000e
(NS_ERROR_OUT_OF_MEMORY)"  location: "JS frame ::
https://bugzilla.mozilla.org/attachment.cgi?id=187326 :: <TOP_LEVEL> :: line 14"
 data: no]"]

Comment 5

[Brendan Eich [:brendan]]

Firefox 1.0.x has stack limiting, but it's generous (512K).  I do not see a
crash on Linux 1.0.3, but the testcase does cause the browser to hog resources
for a long while, then write some results.

Using a -S 500000 stack limit option for the js shell, and the attached testcase
adapted to the shell, I see silent failure due to the stack limit being reached,
very quickly.

The "too much recursion" exception thrown in this case should not be suppressed,
but it is, due to pre-ECMA-262 code that never was changed to match the spec. 
That's a separate bug, which I will file after making sure one isn't already on
file.  This bug should be about the 1.0.x crash, but I can't find the talkback
id reported in comment 2.  Cc'ing Jay for help there.

/be

Comment 6

[Brendan Eich [:brendan]]

What's more (timeless, you might be able to answer this), *why* is the trunk
failing the test promptly with an OOM?

/be

Comment 7

[timeless]

i don't know offhand, my cvs builds aren't remotely close to trunk and have all
sorts of fun variations. sorry.

Comment 8

[Matthias Versen [:Matti]]

Brendan: use my Talkback ID : TB7044683W

JS_GetPrivate 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsapi.c,
line 1999]
nsScriptSecurityManager::GetFramePrincipal 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 1867]
nsScriptSecurityManager::GetPrincipalAndFrame 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 1891]
nsScriptSecurityManager::GetSubjectPrincipal 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 1931]
nsScriptSecurityManager::GetSubjectPrincipal 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 1594]
nsContentUtils::IsCallerChrome 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsContentUtils.cpp,
line 921]
PresShell::HandleEventInternal 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6027]
PresShell::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5921]
nsViewManager::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 2280]
nsViewManager::DispatchEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 2066]
HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/view/src/nsView.cpp,
line 77]
nsWindow::DispatchEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1067]
nsWindow::DispatchFocus 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 5451]
nsWindow::ProcessMessage 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 4216]
nsWindow::WindowProc 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1349]
.......