The following testcase crashes on mozilla-central revision cfdb7af3af2e (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug --enable-optimize, run with --fuzzing-safe --ion-offthread-compile=off --ion-eager): var evalInFrame = (function (global) { var dbgGlobal = newGlobal(); var dbg = new dbgGlobal.Debugger(); return function evalInFrame(upCount, code) { dbg.addDebuggee(global); var frame = dbg.getNewestFrame().older; frame = frame.older; var completion = frame.eval(code); }; })(this); var actual = ''; try { function f() { evalInFrame(1, "print(a)"); } } catch (e) {} loadFile(` actual = ''; for (var i = 0; i < 1000; ++i) f(i); assertEq(actual, expected) `); function loadFile(lfVarx) { let m = parseModule(lfVarx); m.declarationInstantiation(); m.evaluation(); } Backtrace: received signal SIGSEGV, Segmentation fault. 0x0000000000a743e7 in JSObject::as<js::EnvironmentObject> (this=<optimized out>) at js/src/jsobj.h:567 #0 0x0000000000a743e7 in JSObject::as<js::EnvironmentObject> (this=<optimized out>) at js/src/jsobj.h:567 #1 js::EnvironmentIter::environment (this=this@entry=0x7fffffff8650) at js/src/vm/EnvironmentObject.h:697 #2 0x0000000000a4dec6 in GetDebugEnvironmentForEnvironmentObject (ei=..., cx=0x7ffff695f000) at js/src/vm/EnvironmentObject.cpp:2824 #3 GetDebugEnvironment (cx=cx@entry=0x7ffff695f000, ei=...) at js/src/vm/EnvironmentObject.cpp:2931 #4 0x0000000000a4e430 in GetDebugEnvironmentForEnvironmentObject (ei=..., cx=0x7ffff695f000) at js/src/vm/EnvironmentObject.cpp:2829 #5 GetDebugEnvironment (cx=cx@entry=0x7ffff695f000, ei=...) at js/src/vm/EnvironmentObject.cpp:2931 #6 0x0000000000a4e96f in js::GetDebugEnvironmentForFrame (cx=cx@entry=0x7ffff695f000, frame=..., pc=pc@entry=0x7ffff03cf323 ":") at js/src/vm/EnvironmentObject.cpp:2966 #7 0x0000000000a61788 in DebuggerGenericEval (cx=cx@entry=0x7ffff695f000, bindings=bindings@entry=..., options=..., status=@0x7fffffff90cc: 32767, value=..., dbg=0x7ffff693d000, envArg=..., iter=0x7fffffff8bd8, chars=...) at js/src/vm/Debugger.cpp:7498 #8 0x0000000000a62ef0 in js::DebuggerFrame::eval (cx=cx@entry=0x7ffff695f000, frame=frame@entry=..., chars=..., bindings=..., bindings@entry=..., options=..., status=@0x7fffffff90cc: 32767, value=value@entry=...) at js/src/vm/Debugger.cpp:7562 #9 0x0000000000a631ef in js::DebuggerFrame::evalMethod (cx=cx@entry=0x7ffff695f000, argc=<optimized out>, vp=<optimized out>) at js/src/vm/Debugger.cpp:8139 #10 0x0000000000aef2f9 in js::CallJSNative (cx=cx@entry=0x7ffff695f000, native=0xa62f30 <js::DebuggerFrame::evalMethod(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:235 #11 0x0000000000adf783 in js::InternalCallOrConstruct (cx=cx@entry=0x7ffff695f000, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:454 #12 0x0000000000adfab6 in InternalCall (cx=cx@entry=0x7ffff695f000, args=...) at js/src/vm/Interpreter.cpp:499 #13 0x0000000000adfc0e in js::Call (cx=cx@entry=0x7ffff695f000, fval=..., fval@entry=..., thisv=..., args=..., rval=...) at js/src/vm/Interpreter.cpp:518 #14 0x0000000000a0d1fb in js::Wrapper::call (this=this@entry=0x1da6740 <js::CrossCompartmentWrapper::singleton>, cx=cx@entry=0x7ffff695f000, proxy=..., proxy@entry=..., args=...) at js/src/proxy/Wrapper.cpp:165 #15 0x00000000009ce062 in js::CrossCompartmentWrapper::call (this=0x1da6740 <js::CrossCompartmentWrapper::singleton>, cx=0x7ffff695f000, wrapper=..., args=...) at js/src/proxy/CrossCompartmentWrapper.cpp:333 #16 0x00000000009c93b0 in js::Proxy::call (cx=cx@entry=0x7ffff695f000, proxy=proxy@entry=..., args=...) at js/src/proxy/Proxy.cpp:401 #17 0x00000000009c94b2 in js::proxy_Call (cx=cx@entry=0x7ffff695f000, argc=<optimized out>, vp=<optimized out>) at js/src/proxy/Proxy.cpp:690 #18 0x0000000000aef2f9 in js::CallJSNative (cx=cx@entry=0x7ffff695f000, native=0x9c9420 <js::proxy_Call(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:235 #19 0x0000000000adf977 in js::InternalCallOrConstruct (cx=cx@entry=0x7ffff695f000, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:442 #20 0x0000000000adfab6 in InternalCall (cx=cx@entry=0x7ffff695f000, args=...) at js/src/vm/Interpreter.cpp:499 #21 0x0000000000adfbda in js::CallFromStack (cx=cx@entry=0x7ffff695f000, args=...) at js/src/vm/Interpreter.cpp:505 #22 0x0000000000e5fea1 in js::jit::DoCallFallback (cx=0x7ffff695f000, frame=0x7fffffff9af8, stub_=<optimized out>, argc=<optimized out>, vp=0x7fffffff9a98, res=...) at js/src/jit/BaselineIC.cpp:5998 #23 0x00007ffff7e3d08a in ?? () [...] #47 0x0000000000000000 in ?? () rax 0x0 0 rbx 0x7fffffff8650 140737488324176 rcx 0x7ffff6c28a2d 140737333332525 rdx 0x0 0 rsi 0x7ffff6ef7770 140737336276848 rdi 0x7ffff6ef6540 140737336272192 rbp 0x7fffffff8470 140737488323696 rsp 0x7fffffff8460 140737488323680 r8 0x7ffff6ef7770 140737336276848 r9 0x7ffff7fe4740 140737354024768 r10 0x58 88 r11 0x7ffff6b9f750 140737332770640 r12 0x7fffffff8650 140737488324176 r13 0x7fffffff8520 140737488323872 r14 0x7fffffff8668 140737488324200 r15 0x7fffffff84c0 140737488323776 rip 0xa743e7 <js::EnvironmentIter::environment() const+167> => 0xa743e7 <js::EnvironmentIter::environment() const+167>: movl $0x0,0x0 0xa743f2 <js::EnvironmentIter::environment() const+178>: ud2

JSBugMon: Bisection requested, result: autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: https://hg.mozilla.org/mozilla-central/rev/db4c17553be9 user: Jon Coppeard date: Wed Sep 23 15:47:40 2015 +0100 summary: Bug 930414 - Implement ModuleEvaluation method r=shu This iteration took 213.721 seconds to run.

Jon, is bug 930414 a likely regressor?

Here's a simplified test case: var dbgGlobal = newGlobal(); var dbg = new dbgGlobal.Debugger(); dbg.addDebuggee(this); function evalInFrame() { var frame = dbg.getNewestFrame().older.older; frame.eval("1"); }; var actual = ''; try { function f() { evalInFrame(); } } catch (e) {} let m = parseModule(` actual = ''; for (var i = 0; i < 1; ++i) f(i); actual; `); m.declarationInstantiation(); m.evaluation();

Too late to fix in 50.1.0 release

Any updates on this bug, Jon?

I can reproduce this but I'm pretty stumped about what's going on. This bug involves modules and the debugger and it only happens when we force Ion compilation. We have an EnvironmentIter object where hasAnyEnvironmentObject() returns true but ei.environment() asserts because env_ is a global not an EnvironmentObject. Shu, is there any chance you could take a look at this? Alternatively can you suggest how I might approach figuring this out?

(In reply to Jon Coppeard (:jonco) from comment #6) > I can reproduce this but I'm pretty stumped about what's going on. This bug > involves modules and the debugger and it only happens when we force Ion > compilation. We have an EnvironmentIter object where > hasAnyEnvironmentObject() returns true but ei.environment() asserts because > env_ is a global not an EnvironmentObject. > > Shu, is there any chance you could take a look at this? Alternatively can > you suggest how I might approach figuring this out? Sorry for late reply. So the assertion there is a bit misleading. GlobalScope corresponds to 2 environment objects: the global lexical scope, which IS an EnvironmentObject, then the GlobalObject, which is NOT an EnvironmtnObject. The scope chain of the crash is module -> global. The env chain of the crash is global lexical -> global obj. The env chain should be module -> global lexical -> global obj. I didn't get too much time to debug. The fact that it doesn't crash without --ion-eager suggests we aren't picking up the module env correctly for some reason, perhaps when reconstructing the BaselineFrame when bailing out. Does that give you enough to go on to try debugging it again? I don't know when I'll have time to look at this next week.

Jon, you're off the hook. :)

Adding a test for this would be great.

(In reply to Jan de Mooij [:jandem] from comment #10) > Adding a test for this would be great. I can add the fuzz test but it is pretty slow. I'll annotate it as slow.

(In reply to Shu-yu Guo [:shu] from comment #11) > (In reply to Jan de Mooij [:jandem] from comment #10) > > Adding a test for this would be great. > > I can add the fuzz test but it is pretty slow. I'll annotate it as slow. Scratch that, I missed that Jon had already reduced the test case to a nicer one in comment 3. I'll commit that instead.

Pushed by shu@rfrn.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/ca192af3619e Fix computing optimized out module frame environments in RematerializedFrame. (r=jandem)

(In reply to Shu-yu Guo [:shu] from comment #9) Oh hey, thanks for fixing :)