Closed Bug 1213574 Opened 6 years ago Closed 6 years ago

Assertion failure: scope_->as<ClonedBlockObject>().staticBlock() == staticBlock(), at js/src/vm/ScopeObject.cpp:1420

Categories

(Core :: JavaScript Engine, defect)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla44
Tracking Status
firefox44 --- fixed

People

(Reporter: decoder, Assigned: shu)

References

Details

(Keywords: assertion, regression, testcase, Whiteboard: [fuzzblocker] [jsbugmon:update])

Attachments

(1 file)

The following testcase crashes on mozilla-central revision c6ede6f30f3d (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --target=i686-pc-linux-gnu --disable-tests --enable-debug, run with --fuzzing-safe --thread-count=2 --ion-shared-stubs=on --ion-offthread-compile=off --baseline-eager):

var lfcode = new Array();
lfcode.push = loadFile;
lfcode.push(`
let (x) {
    await + x--
}
`);
function loadFile(lfVarx) {
    var lfGlobal = newGlobal();
    lfGlobal.offThreadCompileScript(lfVarx);
    lfGlobal.runOffThreadScript();
}


Backtrace:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x086d89ed in js::ScopeIter::settle (this=this@entry=0xffa68200) at js/src/vm/ScopeObject.cpp:1420
#1  0x086d907d in js::ScopeIter::operator++ (this=this@entry=0xffa68200) at js/src/vm/ScopeObject.cpp:1448
#2  0x08640899 in js::UnwindAllScopesInFrame (cx=cx@entry=0xf7277020, si=...) at js/src/vm/Interpreter.cpp:1299
#3  0x083ead48 in js::jit::DebugEpilogue (cx=0xf7277020, frame=frame@entry=0xffa68660, pc=pc@entry=0xf4f7488f "\232", ok=ok@entry=false) at js/src/jit/VMFunctions.cpp:708
#4  0x0830dbc2 in js::jit::OnLeaveBaselineFrame (cx=cx@entry=0xf7277020, frame=..., pc=0xf4f7488f "\232", rfe=0xffa68614, frameOk=frameOk@entry=false) at js/src/jit/JitFrames.cpp:525
#5  0x083203a9 in HandleExceptionBaseline (pc=<optimized out>, rfe=<optimized out>, frame=..., cx=<optimized out>) at js/src/jit/JitFrames.cpp:758
#6  js::jit::HandleException (rfe=0xffa68614) at js/src/jit/JitFrames.cpp:899
#7  0xf7450335 in ?? ()
#8  0xf7450c5c in ?? ()
#9  0x0822d3c5 in EnterBaseline (cx=0xf4f1b228, cx@entry=0xf7277020, data=...) at js/src/jit/BaselineJIT.cpp:126
#10 0x08231fcd in js::jit::EnterBaselineMethod (cx=cx@entry=0xf7277020, state=...) at js/src/jit/BaselineJIT.cpp:157
#11 0x08662190 in js::RunScript (cx=cx@entry=0xf7277020, state=...) at js/src/vm/Interpreter.cpp:698
#12 0x0866464a in js::ExecuteKernel (cx=cx@entry=0xf7277020, script=..., script@entry=..., scopeChainArg=..., thisv=..., newTargetValue=..., type=js::EXECUTE_GLOBAL, evalInFrame=..., evalInFrame@entry=..., result=result@entry=0xffa68e30) at js/src/vm/Interpreter.cpp:983
#13 0x08664ad7 in js::Execute (cx=cx@entry=0xf7277020, script=script@entry=..., scopeChainArg=..., rval=rval@entry=0xffa68e30) at js/src/vm/Interpreter.cpp:1018
#14 0x084b8d1f in ExecuteScript (cx=cx@entry=0xf7277020, scope=..., scope@entry=..., script=script@entry=..., rval=rval@entry=0xffa68e30) at js/src/jsapi.cpp:4505
#15 0x084b8ea5 in JS_ExecuteScript (cx=cx@entry=0xf7277020, scriptArg=scriptArg@entry=..., rval=rval@entry=...) at js/src/jsapi.cpp:4531
#16 0x080e8f84 in runOffThreadScript (cx=0xf7277020, argc=0, vp=0xffa68e30) at js/src/shell/js.cpp:3438
#17 0x086658fa in js::CallJSNative (cx=0xf7277020, native=0x80e8e90 <runOffThreadScript(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:235
#18 0x08662797 in js::Invoke (cx=cx@entry=0xf7277020, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:767
#19 0x0866372a in js::Invoke (cx=cx@entry=0xf7277020, thisv=..., fval=..., argc=0, argv=0xffa691e0, rval=...) at js/src/vm/Interpreter.cpp:822
#20 0x085cecb2 in js::DirectProxyHandler::call (this=this@entry=0x982db6c <js::CrossCompartmentWrapper::singleton>, cx=cx@entry=0xf7277020, proxy=..., proxy@entry=..., args=...) at js/src/proxy/DirectProxyHandler.cpp:77
#21 0x085c1f2d in js::CrossCompartmentWrapper::call (this=0x982db6c <js::CrossCompartmentWrapper::singleton>, cx=0xf7277020, wrapper=..., args=...) at js/src/proxy/CrossCompartmentWrapper.cpp:289
#22 0x085cdada in js::Proxy::call (cx=cx@entry=0xf7277020, proxy=proxy@entry=..., args=...) at js/src/proxy/Proxy.cpp:412
#23 0x085cdb7a in js::proxy_Call (cx=0xf7277020, argc=0, vp=0xffa691d0) at js/src/proxy/Proxy.cpp:710
#24 0x086658fa in js::CallJSNative (cx=0xf7277020, native=0x85cdb00 <js::proxy_Call(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:235
#25 0x08662797 in js::Invoke (cx=cx@entry=0xf7277020, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:767
#26 0x0866372a in js::Invoke (cx=cx@entry=0xf7277020, thisv=..., fval=..., argc=argc@entry=0, argv=argv@entry=0xffa693f8, rval=rval@entry=...) at js/src/vm/Interpreter.cpp:822
#27 0x083f51c4 in js::jit::InvokeFunction (cx=0xf7277020, obj=..., constructing=false, argc=0, argv=0xffa693f0, rval=...) at js/src/jit/VMFunctions.cpp:96
#28 0xf7456afc in ?? ()
#29 0xffffff88 in ?? ()
#30 0x00000000 in ?? ()
eax	0x0	0
ebx	0x97fbe34	159366708
ecx	0xf760b88c	-144656244
edx	0x0	0
esi	0xffa68200	-5864960
edi	0xf4c85020	-188198880
ebp	0xffa68178	4289102200
esp	0xffa68150	4289102160
eip	0x86d89ed <js::ScopeIter::settle()+989>
=> 0x86d89ed <js::ScopeIter::settle()+989>:	movl   $0x58c,0x0
   0x86d89f7 <js::ScopeIter::settle()+999>:	call   0x8101690 <abort()>
Shu, this is one of the crashes I'm still seeing even after the fuzzblocker fix.

This blocks *all* JS fuzzing, marking as fuzzblocker.
Flags: needinfo?(shu)
Keywords: crash
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update,bisect][fuzzblocker]
Whiteboard: [jsbugmon:update,bisect][fuzzblocker] → [fuzzblocker] [jsbugmon:update]
JSBugMon: Bisection requested, result:
=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20151006132131" and the hash "d6059530b0317e6f6b141582b611469505256be4".
The "bad" changeset has the timestamp "20151006135536" and the hash "cfc1820361f599c55128b29de4332f8d06511e07".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d6059530b0317e6f6b141582b611469505256be4&tochange=cfc1820361f599c55128b29de4332f8d06511e07
Assignee: nobody → shu
Status: NEW → ASSIGNED
Flags: needinfo?(shu)
Comment on attachment 8672306 [details] [diff] [review]
Fix up static scopes inside scripts wrt the static global lexical scope when merging parse task compartments.

Review of attachment 8672306 [details] [diff] [review]:
-----------------------------------------------------------------

decoder asked me to look at this as it's blocking all fuzzing on m-c.

::: js/src/jsgc.cpp
@@ +6742,5 @@
>  
> +    // Get the static global lexical scope of the target compartment. Static
> +    // scopes need to be fixed up below.
> +    RootedObject targetStaticGlobalLexicalScope(rt, &target->maybeGlobal()
> +                                                           ->lexicalScope().staticBlock());

Nit: this syntax is a bit unusual, maybe \n after rt?

@@ +6762,5 @@
> +        if (script->hasBlockScopes()) {
> +            BlockScopeArray* scopes = script->blockScopes();
> +            for (uint32_t i = 0; i < scopes->length; i++) {
> +                uint32_t scopeIndex = scopes->vector[i].index;
> +                ScopeObject* scope = &script->getObject(scopeIndex)->as<ScopeObject>();

Shouldn't we ensure scopeIndex != NoBlockScopeIndex? If we should, can we add a test if there isn't one? :)
Attachment #8672306 - Flags: review+
Blocks: 1213832
(In reply to Jan de Mooij [:jandem] from comment #4)
> Comment on attachment 8672306 [details] [diff] [review]
> Fix up static scopes inside scripts wrt the static global lexical scope when
> merging parse task compartments.
> 
> Review of attachment 8672306 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> @@ +6762,5 @@
> > +        if (script->hasBlockScopes()) {
> > +            BlockScopeArray* scopes = script->blockScopes();
> > +            for (uint32_t i = 0; i < scopes->length; i++) {
> > +                uint32_t scopeIndex = scopes->vector[i].index;
> > +                ScopeObject* scope = &script->getObject(scopeIndex)->as<ScopeObject>();
> 
> Shouldn't we ensure scopeIndex != NoBlockScopeIndex? If we should, can we
> add a test if there isn't one? :)

Hm, good question. I don't think so, because NoBlockScopeIndex is only possible in the "parent" position of the block notes to determine nesting, and I'm not looking at that index here. I'm pretty sure the frontend never adds a block note with an index == NoBlockScopeIndex
Attachment #8672306 - Flags: review?(bhackett1024)
Duplicate of this bug: 1213576
(In reply to Shu-yu Guo [:shu] from comment #5)
> (In reply to Jan de Mooij [:jandem] from comment #4)
> > Comment on attachment 8672306 [details] [diff] [review]
> > Fix up static scopes inside scripts wrt the static global lexical scope when
> > merging parse task compartments.
> > 
> > Review of attachment 8672306 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > @@ +6762,5 @@
> > > +        if (script->hasBlockScopes()) {
> > > +            BlockScopeArray* scopes = script->blockScopes();
> > > +            for (uint32_t i = 0; i < scopes->length; i++) {
> > > +                uint32_t scopeIndex = scopes->vector[i].index;
> > > +                ScopeObject* scope = &script->getObject(scopeIndex)->as<ScopeObject>();
> > 
> > Shouldn't we ensure scopeIndex != NoBlockScopeIndex? If we should, can we
> > add a test if there isn't one? :)
> 
> Hm, good question. I don't think so, because NoBlockScopeIndex is only
> possible in the "parent" position of the block notes to determine nesting,
> and I'm not looking at that index here. I'm pretty sure the frontend never
> adds a block note with an index == NoBlockScopeIndex

Nope, I take that back. Apparently we can totally emit NoBlockScopeIndex...
https://hg.mozilla.org/mozilla-central/rev/db3b6778ae81
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
Blocks: 1214741
Depends on: 1236473
Duplicate of this bug: 1213832
You need to log in before you can comment on or make changes to this bug.