The following testcase crashes on mozilla-central revision 9a358be6fa79 (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): function arrayProtoOutOfRange() { for (let [] = () => r, get;;) var r = f(i % 2 ? a : b); } oomTest(arrayProtoOutOfRange); Backtrace: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x08750d30 in js::ScopeIter::settle (this=this@entry=0xff8385c0) at js/src/vm/ScopeObject.cpp:1417 #1 0x0875107b in js::ScopeIter::ScopeIter(JSContext*, js::AbstractFramePtr, unsigned char*, mozilla::detail::GuardObjectNotifier&&) (this=0xff8385c0, cx=0xf7277020, frame=..., pc=0xf4f3904c "\216\213", _notifier=<unknown type in /home/ubuntu/mozilla-central/js/src/debug32/dist/bin/js, CU 0x3a01cb9, DIE 0x3be6843>) at js/src/vm/ScopeObject.cpp:1386 #2 0x086bd3b4 in HandleError (regs=..., cx=0xf7277020) at js/src/vm/Interpreter.cpp:1168 #3 Interpret (cx=cx@entry=0xf7277020, state=...) at js/src/vm/Interpreter.cpp:3966 #4 0x086cd91d in js::RunScript (cx=cx@entry=0xf7277020, state=...) at js/src/vm/Interpreter.cpp:426 #5 0x086cdc56 in js::Invoke (cx=0xf7277020, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:497 #6 0x086cf7c2 in js::Invoke (cx=cx@entry=0xf7277020, thisv=..., fval=..., argc=argc@entry=0, argv=argv@entry=0x0, rval=rval@entry=...) at js/src/vm/Interpreter.cpp:531 #7 0x08561460 in JS_CallFunction (cx=cx@entry=0xf7277020, obj=..., fun=fun@entry=..., args=..., rval=rval@entry=...) at js/src/jsapi.cpp:2858 #8 0x086e58ab in OOMTest (cx=0xf7277020, argc=1, vp=0xf51150f0) at js/src/builtin/TestingFunctions.cpp:1196 #9 0x086d11ea in js::CallJSNative (cx=0xf7277020, native=0x86e5690 <OOMTest(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:235 #10 0x086cdba1 in js::Invoke (cx=0xf7277020, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:479 #11 0x086bde4b in Interpret (cx=cx@entry=0xf7277020, state=...) at js/src/vm/Interpreter.cpp:2802 #12 0x086cd91d in js::RunScript (cx=cx@entry=0xf7277020, state=...) at js/src/vm/Interpreter.cpp:426 #13 0x086d02a1 in js::ExecuteKernel (cx=cx@entry=0xf7277020, script=..., script@entry=..., scopeChainArg=..., newTargetValue=..., type=type@entry=js::EXECUTE_DIRECT_EVAL, evalInFrame=evalInFrame@entry=..., result=0xff839680) at js/src/vm/Interpreter.cpp:685 #14 0x0822bd1b in EvalKernel (cx=cx@entry=0xf7277020, args=..., evalType=evalType@entry=DIRECT_EVAL, caller=..., scopeobj=..., scopeobj@entry=..., pc=0xf723f8b3 "{") at js/src/builtin/Eval.cpp:334 #15 0x0822c44e in js::DirectEval (cx=cx@entry=0xf7277020, args=...) at js/src/builtin/Eval.cpp:442 #16 0x082657a9 in js::jit::DoCallFallback (cx=0xf7277020, frame=0xff8396c0, stub_=0xf51da870, argc=1, vp=0xff839680, res=...) at js/src/jit/BaselineIC.cpp:6171 #17 0xf743fdbe in ?? () [...] #34 main (argc=5, argv=0xff83a584, envp=0xff83a59c) at js/src/shell/js.cpp:6974 eax 0x0 0 ebx 0x9840434 159646772 ecx 0xf75f488c -144750452 edx 0x0 0 esi 0xff8385c0 -8157760 edi 0xff8385dc -8157732 ebp 0xff838298 4286808728 esp 0xff838270 4286808688 eip 0x8750d30 <js::ScopeIter::settle()+1456> => 0x8750d30 <js::ScopeIter::settle()+1456>: movl $0x589,0x0 0x8750d3a <js::ScopeIter::settle()+1466>: call 0x80feba0 <abort()>

JSBugMon: Bisection requested, result: === Treeherder Build Bisection Results by autoBisect === The "good" changeset has the timestamp "20160105182608" and the hash "01f9ac68f2675488b90414b0a2dd8424214d1e20". The "bad" changeset has the timestamp "20160105183308" and the hash "a70ef4326ea9a7f64ed5a814c860cc7b04b409b0". Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=01f9ac68f2675488b90414b0a2dd8424214d1e20&tochange=a70ef4326ea9a7f64ed5a814c860cc7b04b409b0

Shu-yu, is any of the bugs in the regression window in comment 1 the likely regressor?

Yeah, this was regressed by bug 1234414. Sigh.

Comment on attachment 8711178 [details] [diff] [review] Skip the initial block scope when unwinding scopes due to an exception that's thrown in the prologue before the scope chain is properly initialized for a script that starts with a block scope. Review of attachment 8711178 [details] [diff] [review]: ----------------------------------------------------------------- Well... r=me, assuming you have confidence in the fix. But please ping me on IRC - I'd like to understand this better. ::: js/src/jit-test/tests/gc/bug-1240503.js @@ +1,5 @@ > +function arrayProtoOutOfRange() { > + for (let [] = () => r, get;;) > + var r = f(i % 2 ? a : b); > +} > +oomTest(arrayProtoOutOfRange); So, this test does assert for me on tip. But I changed this test to try to trigger the eval case, rather than the function case (since you fixed both) and that version doesn't assert: function f() { "use strict"; eval(` for (let [] = () => r, get;;) var r = f(i % 2 ? a : b); `); } oomTest(f); Can you get it to assert (without your patch) - or explain why it doesn't? I'd like to have the test. ::: js/src/vm/ScopeObject.cpp @@ +1409,2 @@ > void > ScopeIter::settle() I don't really understand this code. What invariant are we going to all this work to preserve? Is it purely to avoid including objects that may be half-initialized? (If so, could we alternatively fix this by never storing pointers to half-initialized objects in frames?)

Too late for assertion fixes in 46.