1304553 - Assertion failure: this->is<T>(), at js/src/jsobj.h:567 or Crash [@ JSObject::is<js::EnvironmentObject>] or Crash [@ JSObject::getClass] with Debugger

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

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

Comment 1

[Fuzzing Team]

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.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Jon, is bug 930414 a likely regressor?

Comment 3

[Jon Coppeard (:jonco)]

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();

Comment 4

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Too late to fix in 50.1.0 release

Comment 5

[Ryan VanderMeulen [:RyanVM]]

Any updates on this bug, Jon?

Comment 6

[Jon Coppeard (:jonco)]

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?

Comment 7

[Shu-yu Guo [:shu]]

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

Comment 8

[Shu-yu Guo [:shu]]

Attachment: Fix computing optimized out module frame environments in RematerializedFrame.

Comment 9

[Shu-yu Guo [:shu]]

Jon, you're off the hook. :)

Comment 10

[Jan de Mooij [:jandem]]

Adding a test for this would be great.

Comment 11

[Shu-yu Guo [:shu]]

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

Comment 12

[Shu-yu Guo [:shu]]

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

Comment 13

[Pulsebot]

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

Comment 14

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/ca192af3619e

Comment 15

[Jon Coppeard (:jonco)]

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