Last Comment Bug 319683 - mozilla crashes [@ call_enumerate] running a not so special script
: mozilla crashes [@ call_enumerate] running a not so special script
: crash, verified1.8.0.2, verified1.8.1
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
: P1 critical (vote)
: mozilla1.9alpha1
Assigned To: Blake Kaplan (:mrbkap)
: Jason Orendorff [:jorendorff]
Depends on:
  Show dependency treegraph
Reported: 2005-12-09 04:21 PST by Jan-Klaas Kollhof
Modified: 2011-06-13 10:01 PDT (History)
9 users (show)
dveditz: blocking1.8.0.2+
bob: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Fix the crash (1.04 KB, patch)
2006-02-06 17:18 PST, Blake Kaplan (:mrbkap)
mrbkap: review-
Details | Diff | Splinter Review
Fix the crash and don't cause new ones (1.85 KB, patch)
2006-02-06 17:46 PST, Blake Kaplan (:mrbkap)
brendan: review-
Details | Diff | Splinter Review
Yeah, that too (1.93 KB, patch)
2006-02-06 17:52 PST, Blake Kaplan (:mrbkap)
brendan: review+
Details | Diff | Splinter Review
What I checked in (2.16 KB, patch)
2006-02-06 18:07 PST, Blake Kaplan (:mrbkap)
mrbkap: review+
brendan: approval‑branch‑1.8.1+
dveditz: approval1.8.0.2+
Details | Diff | Splinter Review

Description Jan-Klaas Kollhof 2005-12-09 04:21:39 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

the browser crashes when running the following function:

function crash(){
    function f(){
        var x;
        function g(){
            x=1; //reffere anything here or Moz will not crash.
    //apply an object to the __proto__ attribute
    f.__proto__={}; //= [];
    //the following call will cause Moz. to crash

Reproducible: Always

Steps to Reproduce:
1. create an html page with a script
2. use the code provided in the details above
3. add a button or an onload atribute to the html page which runs the crash() function 
4. watch mozilla crash

Actual Results:  
the browser crashes with the feedback agend coming up and WinXP displaying a window asking to stop the process.

Expected Results:  
The script should run without any problems.

I do understand that mozilla is using the __proto__ property on objects for it's prototype chain handling. Though, as neither mozilla's JavaScript specs nor the !ECMAScript specs disallow the use of such properties in the user's script using such properties should neither crash the script execution nor crash the entire browser.

The prototype chain handling should not depend on the __proto__ it should rather use an internal object not directly visible to the script. Prototype chain handling could sill be made accessable to the script by providing function (e.g. as functions like setProto(obj, newProto) and {{{getProto(obj)}}) This way overwriting even those functions will neither affect the script nor the prototype chain handling. A script could still implement the __proto__ property by using getters and setters. The advantage would be that the __protot__ object would only exsist in that script and cause no problems to other scripts.
Comment 1 shutdown 2005-12-09 06:38:16 PST
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051208 Firefox/1.6a1

Stack Signature call_enumerate be01b64f 
Product ID FirefoxTrunk 
Build ID 2005120805 
Trigger Time 2005-12-09 05:34:53.0 
Platform Win32 
Operating System Windows 98 4.10 build 67766222 
Module JS3250.DLL + (0001b1b9) 
URL visited  
User Comments Bug 319683 
Since Last Crash 1924 sec 
Total Uptime 1924 sec 
Trigger Reason Access violation 
Source File, Line No. c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsfun.c, line 778 
Stack Trace  

call_enumerate  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsfun.c, line 778]
js_PutCallObject  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsfun.c, line 602]
js_Invoke  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1247]
js_Interpret  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 3756]
js_Invoke  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1231]
js_Interpret  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 3756]
js_Invoke  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1231]
js_InternalInvoke  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1308]
JS_CallFunctionValue  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsapi.c, line 4157]
nsJSContext::CallEventHandler  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1424]
nsJSEventListener::HandleEvent  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/dom/src/events/nsJSEventListener.cpp, line 195]
nsEventListenerManager::HandleEventSubType  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp, line 1685]
nsEventListenerManager::HandleEvent  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp, line 1792]
nsGenericElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp, line 2196]
nsGenericHTMLElement::HandleDOMEventForAnchors  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/html/content/src/nsGenericHTMLElement.cpp, line 1459]
nsHTMLAnchorElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/html/content/src/nsHTMLAnchorElement.cpp, line 292]
PresShell::HandleEventInternal  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 6027]
PresShell::HandleEventWithTarget  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 5925]
nsEventStateManager::CheckForAndDispatchClick  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp, line 2971]
nsEventStateManager::PostHandleEvent  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp, line 1959]
PresShell::HandleEventInternal  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 6081]
PresShell::HandleEvent  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 5863]
nsViewManager::HandleEvent  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/view/src/nsViewManager.cpp, line 2545]
nsViewManager::DispatchEvent  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/view/src/nsViewManager.cpp, line 2237]
HandleEvent  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/view/src/nsView.cpp, line 176]
nsWindow::DispatchEvent  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 1162]
nsWindow::DispatchMouseEvent  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 6007]
ChildWindow::DispatchMouseEvent  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 6213]
nsWindow::WindowProc  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 1351]
KERNEL32.DLL + 0x363b (0xbff7363b)
KERNEL32.DLL + 0x24497 (0xbff94497)
Comment 2 Aiko 2005-12-09 08:24:23 PST
Crashes the latest JS debug shell as well:
Assertion failure: obj && prop, at jsfun.c:776
Comment 3 Bob Clary [:bc:] 2005-12-30 14:27:18 PST
/cvsroot/mozilla/js/tests/js1_5/Regress/regress-319683.js,v  <--  regress-319683.js
Comment 4 Blake Kaplan (:mrbkap) 2006-02-06 17:18:09 PST
Created attachment 210951 [details] [diff] [review]
Fix the crash

This has r=brendan. I'm checking it in now. Nominating for the branches, since this is an extremely trivial null-defense patch.

Note that the variables defined in f() are going to be unusable, but at least we don't crash. This is a real case of "don't do that!" if you want your stuff to work.
Comment 5 Blake Kaplan (:mrbkap) 2006-02-06 17:43:20 PST
Comment on attachment 210951 [details] [diff] [review]
Fix the crash

This could potentially cause crashes.
Comment 6 Blake Kaplan (:mrbkap) 2006-02-06 17:46:46 PST
Created attachment 210958 [details] [diff] [review]
Fix the crash and don't cause new ones

I'm not _entirely_ sure about the check for obj != pobj, but it seems sane to me.
Comment 7 Brendan Eich [:brendan] 2006-02-06 17:49:01 PST
Comment on attachment 210958 [details] [diff] [review]
Fix the crash and don't cause new ones

Need to OBJ_DROP_PROPERTY if prop && pobj != obj.

Comment 8 Blake Kaplan (:mrbkap) 2006-02-06 17:52:34 PST
Created attachment 210959 [details] [diff] [review]
Yeah, that too
Comment 9 Brendan Eich [:brendan] 2006-02-06 17:57:29 PST
Comment on attachment 210959 [details] [diff] [review]
Yeah, that too

Looks good, but is vec really something that belongs to an object ("wrong object's vector")? Might re-word to say "slots vector" -- also mention mutable __proto__ and cloned function object trouble?

Comment 10 Blake Kaplan (:mrbkap) 2006-02-06 18:06:36 PST
Fix checked into trunk.
Comment 11 Blake Kaplan (:mrbkap) 2006-02-06 18:07:33 PST
Created attachment 210963 [details] [diff] [review]
What I checked in
Comment 12 Stephen Donner [:stephend] 2006-02-09 08:15:55 PST
Verified FIXED using trunk Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060209 Firefox/1.6a1
Comment 13 Daniel Veditz [:dveditz] 2006-02-22 01:04:08 PST
Comment on attachment 210963 [details] [diff] [review]
What I checked in

approved for 1.8.0 branch, a=dveditz
Comment 14 Blake Kaplan (:mrbkap) 2006-02-22 16:27:34 PST
Fix checked into the 1.8 branches.
Comment 15 Bob Clary [:bc:] 2006-03-02 11:17:58 PST
v ff 20060302 win/linux/mac

Note You need to log in before you can comment on or make changes to this bug.