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.

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

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? :)

(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

(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...