635599 - Assertion failure: isScriptFrame() // GC related Crash @ js::Bindings::countArgsAndVars

Status: RESOLVED DUPLICATE of bug 635811

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

Attachment: Testcase, run with both -j and -m

The attached testcase (shell with -j,-m) causes the following assertion on TM tip:

Assertion failure: isScriptFrame(), at ../jsinterp.h:278

Passing through the assertion reveals a garbage collector related crash:

Program received signal SIGSEGV, Segmentation fault.
0x00000000004110fa in js::Bindings::countArgsAndVars (this=0xdededede00700072) at ../jsscript.h:198
198         uintN countArgsAndVars() const { return nargs + nvars; }
(gdb) bt
#0  0x00000000004110fa in js::Bindings::countArgsAndVars (this=0xdededede00700072) at ../jsscript.h:198
#1  0x00000000004a873a in call_trace (trc=0x7ffffff899d0, obj=0x7ffff690e0b0) at jsfun.cpp:1385
#2  0x00000000004fabea in js_TraceObject (trc=0x7ffffff899d0, obj=0x7ffff690e0b0) at jsobj.cpp:6552
#3  0x00000000004b0f41 in MarkChildren (trc=0x7ffffff899d0, obj=0x7ffff690e0b0) at jsgcinlines.h:289
#4  0x00000000004b117a in TypedMarker (trc=0x7ffffff899d0, thing=0x7ffff690e0b0) at jsgcinlines.h:347
#5  0x00000000004bb3f0 in Mark<JSObject_Slots2> (trc=0x7ffffff899d0, thing=0x7ffff690e0b0) at jsgcinlines.h:222
#6  0x00000000004c1a18 in js::gc::Arena<JSObject_Slots2>::mark (this=0x7ffff690e000, thing=0x7ffff690e0b0, trc=0x7ffffff899d0) at jsgc.cpp:226
#7  0x00000000004b69d7 in MarkCell<JSObject_Slots2> (cell=0x7ffff690e0b0, trc=0x7ffffff899d0) at jsgc.cpp:583
#8  0x00000000004bce78 in js::MarkIfGCThingWord (trc=0x7ffffff899d0, w=140737330077872, thingKind=@0x7ffffff8987c) at jsgc.cpp:649
#9  0x00000000004b2796 in MarkWordConservatively (trc=0x7ffffff899d0, w=140737330077872) at jsgc.cpp:712
#10 0x00000000004b28c4 in MarkRangeConservatively (trc=0x7ffffff899d0, begin=0x7ffffff89b20, end=0x7ffffffff000) at jsgc.cpp:743
#11 0x00000000004b2977 in MarkThreadDataConservatively (trc=0x7ffffff899d0, td=0x7ffff7e5d360) at jsgc.cpp:760
#12 0x00000000004b2a19 in js::MarkConservativeStackRoots (trc=0x7ffffff899d0) at jsgc.cpp:800
#13 0x00000000004b44ea in js::MarkRuntime (trc=0x7ffffff899d0) at jsgc.cpp:1651
#14 0x00000000004b5893 in MarkAndSweep (cx=0xb05530, gckind=GC_NORMAL) at jsgc.cpp:2407
#15 0x00000000004b5db9 in GCUntilDone (cx=0xb05530, comp=0x0, gckind=GC_NORMAL) at jsgc.cpp:2750
#16 0x00000000004b5f86 in js_GC (cx=0xb05530, comp=0x0, gckind=GC_NORMAL) at jsgc.cpp:2819
#17 0x00000000004280f4 in JS_GC (cx=0xb05530) at jsapi.cpp:2563
#18 0x0000000000407a78 in GC (cx=0xb05530, argc=0, vp=0x7ffff6a920a0) at js.cpp:1404
#19 0x00000000004d3f82 in js::CallJSNative (cx=0xb05530, native=0x407a21 <GC>, argc=0, vp=0x7ffff6a920a0) at jscntxtinlines.h:701
#20 0x00000000006a0cc3 in CallCompiler::generateNativeStub (this=0x7ffffff8a580) at ./methodjit/MonoIC.cpp:808
#21 0x000000000069cf10 in js::mjit::ic::NativeCall (f=..., ic=0xb6b9e8) at ./methodjit/MonoIC.cpp:1016


Security lock and blocker nomination because of crash/possible security problem.

Comment 1

[Christian Holler (:decoder)]

Tested this on x86 with mozilla-central and it also asserts with

Assertion failure: hasCallObj(), at jsinterpinlines.h:479

and then crashes after a few other asserts.

Tried optimized builds on both platforms and got no crash (maybe different gc timing/strategy there?)

The bug itself seems to be no recent regression but an old bug, I didn't get a reliable bisect though (maybe introduced with MethodJIT).

Comment 2

[David Mandelin [:dmandelin]]

Is this also the call_trace crash?

Comment 3

[Luke Wagner [:luke]]

Since there are generators at play, I think this falls into bug 635811 comment 3.  So we should re-test this with bug 635811's patch.

Comment 4

[Johnathan Nightingale [:johnath]]

DMandelin and Waldo have talked themselves into believing this might be sg:crit - final+

Comment 5

[Jeff Walden [:Waldo]]

Shifting to Luke since he thinks it's probably the other bug he already has a handle on, more or less.

Comment 6

[Luke Wagner [:luke]]

I was wrong in comment 3; generators don't have a problem.  But this is a dup of bug 635811 (as can be seen by applying the asserting patch in that bug).