360701 - Crash in js1_7/extensions/regress-355410.js browser with WAY_TOO_MUCH_GC

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Bob Clary [:bc] (inactive)]

I crash in js1_7/regress/regress-355410.js browser with WAY_TOO_MUCH_GC with related stacks in windows (accessing deleted memory) and linux (null pointer deref). 

Linux

#0  0x00000000 in ?? ()

#1  0x00177cf3 in js_GetLengthProperty (cx=0x983b8c8, obj=0x98d29f0, lengthp=0xbfc1b6a0) at mozilla/js/src/jsarray.c:174

#2  0x00178a85 in array_addProperty (cx=0x983b8c8, obj=0x98d29f0, id=3, vp=0xbfc1b83c) at mozilla/js/src/jsarray.c:455

#3  0x001ecb2b in js_SetProperty (cx=0x983b8c8, obj=0x98d29f0, id=3, vp=0xbfc1b83c) at mozilla/js/src/jsobj.c:3641

#4  0x0017825e in SetArrayElement (cx=0x983b8c8, obj=0x98d29f0, index=1, v=160246080) at mozilla/js/src/jsarray.c:299

#5  0x001794fd in InitArrayElements (cx=0x983b8c8, obj=0x98d29f0, start=2, end=2, vector=0xbfc1b8f0) at mozilla/js/src/jsarray.c:733

#6  0x001795f8 in InitArrayObject (cx=0x983b8c8, obj=0x98d29f0, length=2, vector=0xbfc1b8e8) at mozilla/js/src/jsarray.c:756

#7  0x0017bc94 in js_NewArrayObject (cx=0x983b8c8, length=2, vector=0xbfc1b8e8) at mozilla/js/src/jsarray.c:1900

#8  0x001d7e90 in NewKeyValuePair (cx=0x983b8c8, key=160124432, val=160246080, rval=0xbfc1c26c) at mozilla/js/src/jsiter.c:208

#9  0x001d9844 in CallEnumeratorNext (cx=0x983b8c8, iterobj=0x98d29b0, flags=7, rval=0xbfc1c26c) at mozilla/js/src/jsiter.c:563

#10 0x001d9bb8 in js_CallIteratorNext (cx=0x983b8c8, iterobj=0x98d29b0, rval=0xbfc1c26c) at mozilla/js/src/jsiter.c:603

#11 0x001ba6b6 in js_Interpret (cx=0x983b8c8, pc=0x98ca79a "j\a", result=0xbfc1c620) at mozilla/js/src/jsinterp.c:2722

#12 0x001b624f in js_Execute (cx=0x983b8c8, chain=0x983f4a8, script=0x93d8fd0, down=0x0, flags=0, result=0xbfc1c72c) at mozilla/js/src/jsinterp.c:1643

#13 0x001759d1 in JS_EvaluateUCScriptForPrincipals (cx=0x983b8c8, obj=0x983f4a8, principals=0x94edcf4, chars=0x98c4d58, length=2761, filename=0x98cc7c0 "http://test.mozilla.com/tests/mozilla.org/js/js1_7/regress/regress-355410.js", lineno=1, 
    rval=0xbfc1c72c) at mozilla/js/src/jsapi.c:4302

#14 0x02b4009f in nsJSContext::EvaluateString (this=0x981edb8, aScript=@0x9893c5c, aScopeObject=0x983f4a8, aPrincipal=0x94edcf0, aURL=0x98cc7c0 "http://test.mozilla.com/tests/mozilla.org/js/js1_7/regress/regress-355410.js", aLineNo=1, aVersion=170, 
    aRetValue=0x0, aIsUndefined=0xbfc1c840) at mozilla/dom/src/base/nsJSEnvironment.cpp:1306

#15 0x0294e2d1 in nsScriptLoader::EvaluateScript (this=0x96a8368, aRequest=0x9893c48, aScript=@0x9893c5c) at mozilla/content/base/src/nsScriptLoader.cpp:613

winxp

+		cx	0x02e2f180 {links={...} interpLevel=1 stackLimit=719252 ...}	JSContext *

+		obj	0x038f8088 {map=0x038f7f90 slots=0x02cb83b4 }	JSObject *

+		slotp	0x0012eb64	unsigned long *

		nslots	8	unsigned long

+		map	0x0396b5e8 {nrefs=-572662307 ops=0xdddddddd nslots=8 ...}	JSObjectMap *

+		clasp	0x0053ffa0 _js_ArrayClass {name=0x0053ff94 "Array" flags=50331648 addProperty=0x0043d9b0 ...}	JSClass *

+		newslots	0x02cb83b4	long *


js3250.dll!js_AllocSlot(JSContext * cx=0x02e2f180, JSObject * obj=0x038f8088, unsigned long * slotp=0x0012eb64)  Line 2741 + 0xc bytes	C

js3250.dll!js_AddScopeProperty(JSContext * cx=0x02e2f180, JSScope * scope=0x0396b5e8, long id=3, int (JSContext *, JSObject *, long, long *)* getter=0x00000000, int (JSContext *, JSObject *, long, long *)* setter=0x00000000, unsigned long slot=4294967295, unsigned int attrs=1, unsigned int flags=0, int shortid=0)  Line 1129 + 0x16 bytes	C

js3250.dll!js_SetProperty(JSContext * cx=0x02e2f180, JSObject * obj=0x038f8088, long id=3, long * vp=0x0012ec74)  Line 3626 + 0x27 bytes	C

js3250.dll!SetArrayElement(JSContext * cx=0x02e2f180, JSObject * obj=0x038f8088, unsigned long index=1, long v=59736144)  Line 299 + 0x1d bytes	C

js3250.dll!InitArrayElements(JSContext * cx=0x02e2f180, JSObject * obj=0x038f8088, unsigned long start=1, unsigned long end=2, long * vector=0x0012ecf0)  Line 733 + 0x23 bytes	C

js3250.dll!InitArrayObject(JSContext * cx=0x02e2f180, JSObject * obj=0x038f8088, unsigned long length=2, long * vector=0x0012ecec)  Line 756 + 0x17 bytes	C

js3250.dll!js_NewArrayObject(JSContext * cx=0x02e2f180, unsigned long length=2, long * vector=0x0012ecec)  Line 1900 + 0x15 bytes	C

js3250.dll!NewKeyValuePair(JSContext * cx=0x02e2f180, long key=60037888, long val=59736144, long * rval=0x0012f714)  Line 208 + 0xf bytes	C

js3250.dll!CallEnumeratorNext(JSContext * cx=0x02e2f180, JSObject * iterobj=0x038f8090, unsigned int flags=7, long * rval=0x0012f714)  Line 563 + 0x17 bytes	C

js3250.dll!js_CallIteratorNext(JSContext * cx=0x02e2f180, JSObject * iterobj=0x038f8090, long * rval=0x0012f714)  Line 603 + 0x15 bytes	C

js3250.dll!js_Interpret(JSContext * cx=0x02e2f180, unsigned char * pc=0x03936c4a, long * result=0x0012f78c)  Line 2722 + 0x14 bytes	C

js3250.dll!js_Execute(JSContext * cx=0x02e2f180, JSObject * chain=0x038f6ff8, JSScript * script=0x03937350, JSStackFrame * down=0x00000000, unsigned int flags=0, long * result=0x0012f8b8)  Line 1643 + 0x13 bytes	C

js3250.dll!JS_EvaluateUCScriptForPrincipals(JSContext * cx=0x02e2f180, JSObject * obj=0x038f6ff8, JSPrincipals * principals=0x02af6afc, const unsigned short * chars=0x0395fba8, unsigned int length=2761, const char * filename=0x0392f690, unsigned int lineno=1, long * rval=0x0012f8b8)  Line 4302 + 0x19 bytes	C

gklayout.dll!nsJSContext::EvaluateString(const nsAString_internal & aScript={...}, void * aScopeObject=0x038f6ff8, nsIPrincipal * aPrincipal=0x02af6af8, const char * aURL=0x0392f690, unsigned int aLineNo=1, unsigned int aVersion=170, nsAString_internal * aRetValue=0x00000000, int * aIsUndefined=0x0012f9a0)  Line 1306 + 0x43 bytes	C++

gklayout.dll!nsScriptLoader::EvaluateScript(nsScriptLoadRequest * aRequest=0x039295a0, const nsString & aScript={...})  Line 613 + 0x63 bytes	C++

Comment 1

[Igor Bukanov]

The crash happens only on trunk?

Comment 2

[Bob Clary [:bc] (inactive)]

(In reply to comment #1)
> The crash happens only on trunk?
> 

I tried to run the test suite on 1.8.0 and 1.8.1 with WAY_TOO_MUCH_GC but it wouldn't even begin to complete, so I can't be sure what is the full situation on 1.8.x. I'll check this one in particular later today.

Comment 3

[Bob Clary [:bc] (inactive)]

(In reply to comment #1)
> The crash happens only on trunk?

Also crashes on 1.8.1.x with somewhat different stacks, but 1.8.0.x just stops executing the testcase. Tested on Linux and WinXp.

Comment 4

[Jesse Ruderman]

Does this crash still occur on trunk and/or branch?

Does this only happen in the browser, not in the js shell?

Rumor has it that Firefox takes a long time to start with WAY_TOO_MUCH_GC.  What's the best way to run just this test?  ./firefox -chrome (some simple page), to avoid having to load and run all of the JavaScript that makes up Firefox with WAY_TOO_MUCH_GC?  Use Camino instead of Firefox?  Use the runtime gc vigor patch in bug 308429?

Comment 5

[Bob Clary [:bc] (inactive)]

I can't reproduce this in the shell for 1.8.1,1.9.0 on windows or linux. As you say, the browser tests will take longer.

Comment 6

[Bob Clary [:bc] (inactive)]

I also can no longer reproduce this on trunk|winxp in the browser. I recommend -> WFM and removing the blocking nominations.

bug 308429 seems like fodder for additional class of tests.

Comment 7

[Jesse Ruderman]

Do you feel like retesting branch (browser) too?

Comment 8

[Bob Clary [:bc] (inactive)]

Ok, the previous windows crash and stack along with the deleted map->ops is reproducible in 1.8 with way too much gc.

Comment 9

[chris hofmann]

any ideas on next steps for this?

Comment 10

[Blake Kaplan (:mrbkap) (inactive)]

Assigning to Igor, but Crowder might jump in.

Comment 11

[Daniel Veditz [:dveditz]]

Not seeing enough progress to think blocking 1.8.1.5 is realistic.

Since this is branch-only would it be worth trying to find a range when the trunk got fixed?

Comment 12

[Bob Clary [:bc] (inactive)]

fyi, with WAY_TOO_MUCH_GC today's winxp 1.8.1 debug asserts offsetInArena < GC_THINGS_SIZE in js_GetGCThingFlags and linux still crashes although the stack can vary a bit...

#6  0x00000000 in ?? ()
#7  0x00134493 in js_GetLengthProperty (cx=0x9f644f0, obj=0xa196ed0, 
    lengthp=0xbfb10ce0)
    at /work/mozilla/builds/1.8.1-too-much-gc/mozilla/js/src/jsarray.c:174
#8  0x00135219 in array_addProperty (cx=0x9f644f0, obj=0xa196ed0, id=3, 
    vp=0xbfb10e4c)
    at /work/mozilla/builds/1.8.1-too-much-gc/mozilla/js/src/jsarray.c:455
#9  0x001aa9e5 in js_SetProperty (cx=0x9f644f0, obj=0xa196ed0, id=3, 
    vp=0xbfb10e4c)
    at /work/mozilla/builds/1.8.1-too-much-gc/mozilla/js/src/jsobj.c:3764
#10 0x001349f2 in SetArrayElement (cx=0x9f644f0, obj=0xa196ed0, index=1, 
    v=169227016)
    at /work/mozilla/builds/1.8.1-too-much-gc/mozilla/js/src/jsarray.c:299
#11 0x00135c7f in InitArrayElements (cx=0x9f644f0, obj=0xa196ed0, start=2, 
    end=2, vector=0xbfb10f00)
    at /work/mozilla/builds/1.8.1-too-much-gc/mozilla/js/src/jsarray.c:733

this was before Igor's checkins for Bug 393537, Bug 387955, Bug 390078.

Comment 13

[Igor Bukanov]

What is the current way to run the test in a browser? If I use

file:///home/igor/m/trunk/mozilla/js/tests/js-test-driver-standards.html?test=js1_7/extensions/regress-355410.js;language=language;version=JavaScript1.7

then it just shows an empty page.

Comment 14

[Bob Clary [:bc] (inactive)]

I'm not sure why the test fails to run from file://. I've added the url to bclary.com for your convenience.

Comment 15

[Igor Bukanov]

It turned out that file: URL runs with language=type

Comment 16

[Igor Bukanov]

Here is a variation of the test case that crashes on 1.8.1 in jsshell with WAY_TOO_MUCH_GC:

function f(v) {
    new Object();
    this[-1] = 0;
}

Array.prototype.__defineSetter__(0, f);

for(var [key, value] in { elem: 0 } ) { print(1); }

~/m/1.8.1/mozilla/js/src $ ./Linux_All_DBG.OBJ/js -v 170 ~/m/y.js
segmentation fault

The crash happens due to the following reasons:

1. The iterator implementation uses js_NewArrayObject to create 2-element array. The function creates array's object and assigns its 2 elements using js_SetProperty assuming that weak rooting works.

2. The first js_SetProperty invokes the setter from Array.prototype.0. During the invocation of the setter the object is strongly rooted. But its implementation displaces array's object from the weak roots via new Object(). Thus, when js_SetProperty returns, array's object will be unrooted. Then the setter adds -1 property to the array. That brings the number of the used slots in the object to 5 meaning that there is no more space for more slots in the preallocated slot's array. 

3. The second invocation of js_SetProperty tries to add a new slot to the array when it initializes the second element. That triggers the allocation of the new slot array via js_NewGCThing as 1.8.1 branch allocates small slots arrays as GC things. With WAY_TOO_MUCH_GC defined that causes the last ditch GC. Since array's object is no longer rooted, it is collected leading to the crash.

Comment 17

[Daniel Veditz [:dveditz]]

Is there any chance of getting this fixed on the 1.8 branch?

Comment 18

[Daniel Veditz [:dveditz]]

Would still like this fixed on the branch to head off potential problems. I guess not a "blocker" because so far we don't know of a reliable way to cause this crash without WAY_TOO_MUCH_GC, although there may be one.

Comment 19

[Igor Bukanov]

The bug was fixed on branches when the branch patches for bug 372309 has landed.