1877954 - Assertion failure: callObj->callee().isGeneratorOrAsync(), at vm/EnvironmentObject.cpp:2463

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

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

oomTest(function () {
    eval(`
      for (let x = 0, y = 9; y; ) {
        (function() {
          y--;
          let z = {};
          z.sameZoneAs = [];
          newGlobal(z).Debugger(this).getNewestFrame().environment;
        })()}
    `);
});

(gdb) bt
#0  js::DebugEnvironmentProxy::initSnapshot (this=0x41c1da45f90, o=...) at /home/gen32gx500/trees/mozilla-central/js/src/vm/EnvironmentObject.cpp:2463
#1  0x00005555573586fc in js::DebugEnvironments::takeFrameSnapshot (cx=cx@entry=0x7ffff6631500, debugEnv=debugEnv@entry=..., frame=...)
    at /home/gen32gx500/trees/mozilla-central/js/src/vm/EnvironmentObject.cpp:2832
#2  0x000055555737a0a0 in js::DebugEnvironments::onPopGeneric<js::ScopedLexicalEnvironmentObject, js::LexicalScope> (cx=0x7ffff6631500, ei=...)
    at /home/gen32gx500/trees/mozilla-central/js/src/vm/EnvironmentObject.cpp:2915
#3  0x00005555571a0aa2 in PopEnvironment (cx=cx@entry=0x7ffff6631500, ei=...) at /home/gen32gx500/trees/mozilla-central/js/src/vm/Interpreter.cpp:1044
#4  0x00005555571a0d2b in js::UnwindAllEnvironmentsInFrame (cx=cx@entry=0x7ffff6631500, ei=...) at /home/gen32gx500/trees/mozilla-central/js/src/vm/Interpreter.cpp:1128
#5  0x000055555763106c in js::InterpreterFrame::epilogue (this=0x7ffff64520b8, cx=0x7ffff6631500, pc=0x7ffff575397e "\322\001")
    at /home/gen32gx500/trees/mozilla-central/js/src/vm/Stack.cpp:211
#6  0x00005555571a2f6e in js::Interpret (cx=0x7ffff6631500, state=...) at /home/gen32gx500/trees/mozilla-central/js/src/vm/Interpreter.cpp:4404
#7  0x000055555719ba59 in MaybeEnterInterpreterTrampoline (cx=0x7ffff7e37700 <_IO_stdfile_2_lock>, cx@entry=0x7ffff6631500, state=...)
    at /home/gen32gx500/trees/mozilla-central/js/src/vm/Interpreter.cpp:394
#8  0x000055555719b70f in js::RunScript (cx=cx@entry=0x7ffff6631500, state=...) at /home/gen32gx500/trees/mozilla-central/js/src/vm/Interpreter.cpp:452
#9  0x000055555719ecec in js::ExecuteKernel (cx=0x7ffff6631500, script=script@entry=..., envChainArg=envChainArg@entry=..., evalInFrame=evalInFrame@entry=..., 
    result=result@entry=...) at /home/gen32gx500/trees/mozilla-central/js/src/vm/Interpreter.cpp:839
#10 0x00005555571ffc16 in EvalKernel (cx=0x7ffff6631500, v=v@entry=..., evalType=evalType@entry=DIRECT_EVAL, caller=..., env=env@entry=..., pc=0x7ffff663d4a1 "y\001", 
    vp=...) at /home/gen32gx500/trees/mozilla-central/js/src/builtin/Eval.cpp:352
#11 0x000055555720170a in js::DirectEval (cx=cx@entry=0x7ffff6631500, v=..., vp=...) at /home/gen32gx500/trees/mozilla-central/js/src/builtin/Eval.cpp:379
#12 0x0000555557d7a5f1 in js::jit::DoCallFallback (cx=0x7ffff6631500, frame=0x7fffffffbfb8, stub=0x7ffff66b2b90, argc=1, vp=0x7fffffffbf68, res=...)
    at /home/gen32gx500/trees/mozilla-central/js/src/jit/BaselineIC.cpp:1644
/snip

Run with --fuzzing-safe --no-threads --no-baseline --no-ion, compile with AR=ar sh ../configure --enable-debug --enable-debug-symbols --with-ccache --enable-nspr-build --enable-ctypes --enable-gczeal --enable-rust-simd --disable-tests, tested on m-c rev 93128c0fb8fe.

Setting s-s to be safe.

Comment 1

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

Attachment: debug stack

Comment 2

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

I couldn't get this to crash on the latest debug js shells on FTP as of 2015-10-21, but it crashes on m-c rev a5887514ddfb (early-Feb 2022) with the assertion message Assertion failure: CallObject::find(&environment())->callee().isGeneratorOrAsync(), at vm/EnvironmentObject.cpp:2402.

Jan, do you mind taking a look to see if this is benign? Maybe related to bug 1684821?

Comment 3

[Jan de Mooij [:jandem]]

This seems to be an OOM issue involving the debugger and FreshenLexicalEnv. The interpreter implementation of this opcode is:

  if (MOZ_UNLIKELY(cx->realm()->isDebuggee())) {
    DebugEnvironments::onPopLexical(cx, REGS.fp(), REGS.pc);
  }
  if (!REGS.fp()->freshenLexicalEnvironment(cx)) {
    goto error;
  }

We call DebugEnvironmentProxy::initSnapshot under the onPopLexical to assign a snapshot, but then we fail to actually replace the lexical environment object under freshenLexicalEnvironment. We report OOM, the exception handler unwinds all environments, and tries to take another snapshot. This asserts because already took one before.

Best fix would be to call onPopLexical after cloning the environment object.

Comment 4

[Jan de Mooij [:jandem]]

I can't open this up because it's still in the Core Security group instead of JS Security, but this isn't security sensitive. It requires use of the debugger API and even then, snapshotting for a debug environment proxy twice isn't bad; we just overwrite the snapshot with an identical one.

Comment 5

[Jan de Mooij [:jandem]]

Attachment: Bug 1877954 - Call DebugEnvironments::onPopLexical after allocating the new environment object. r?iain!

Allocating the new environment object can OOM and in this case we were calling onPopLexical
twice for the same environment object. This triggers an assertion failure in the frame snapshot code.

No test because the test case is really slow.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5a7e539d390a
Call DebugEnvironments::onPopLexical after allocating the new environment object. r=iain

Comment 7

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/5a7e539d390a