1893554 - Assertion failure: rematFrame->script() == frame->script(), at jit/BaselineBailouts.cpp:1783

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect, P1)

Description

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

g = newGlobal({ newCompartment: true });
g.parent = this;
g.eval(
  "(" +
    function () {
      Debugger(parent).onExceptionUnwind = function (frame) {
        frame.older;
      };
    } +
    ")()"
);
function f(x, y) {
  try {
    Object.setPrototypeOf(
      y,
      new Proxy(Object.getPrototypeOf(y), {
        get(aaaaaa, bbb, ccccccc) {
          return undefined;
        },
      })
    );
  } catch (e) {}
}
function h(x, y) {
  f(x, y);
}
oomTest(function () {
  h("", undefined);
  h("", "");
  "".replaceAll();
});

1783      MOZ_ASSERT(rematFrame->script() == frame->script());
(gdb) bt
#0  CopyFromRematerializedFrame (cx=0x7ffff7640600, act=0x7fffffffc170, fp=0x7fffffffc030 "p\300\377\377\377\177", inlineDepth=0, frame=<optimized out>) at /home/ubumain/trees/mozilla-central/js/src/jit/BaselineBailouts.cpp:1783
#1  js::jit::FinishBailoutToBaseline (bailoutInfoArg=0x0) at /home/ubumain/trees/mozilla-central/js/src/jit/BaselineBailouts.cpp:1949
#2  0x000020c9f309e1ba in ?? ()
#3  0x0000000000000000 in ?? ()
(gdb)

Run with --fuzzing-safe --ion-eager, 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 66b11776bfaa.

Setting s-s as a start. This testcase is quite intermittent, probably once in 50/100 tries.

(EDIT: This bisection comment is not right) Bisection is currently pointing to late-Aug 2023 to late-Oct 2023...

Comment 1

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

Bisection is currently pointing to late-Aug 2023 to late-Oct 2023...

This is not right, it gets even more intermittent in past revs. It still seems to occur in m-c rev 443c7bf9d76b (Aug 2023) though.

Setting needinfo? from Jan as a start, Iain is also on cc as this involves Debugger and the JIT.

Comment 2

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

I've also found that reproduction helps with fuzzing running in the background to use up system resources.

Comment 3

[Jan de Mooij [:jandem]]

I've been unable to reproduce this so far. I also tried about 500 runs with rr chaos mode.

Do you also see this with ASan builds?

Comment 4

[Jan de Mooij [:jandem]]

Nevermind, I got a failure after ~700 runs under rr :)

Comment 5

[Jan de Mooij [:jandem]]

DebuggerFrame::getOlder has this code:

      if (dbg->observesFrame(iter)) {
        if (iter.isIon() && !iter.ensureHasRematerializedFrame(cx)) {
          return false;
        }
        return dbg->getFrame(cx, iter, result);
      }

I think the bug is that we create a rematerialized frame for the Ion frame, but we then OOM under getFrame so we never invalidate the Ion frame. Because we don't invalidate the Ion frame, we return from the Ion frame to the caller without removing the rematerialized frame from the hash map. This confuses later code that does a lookup on the rematerialized-frame table because it finds the stale frame.

We should at least add better assertions for rematerialized frame lifetimes.

Comment 6

[Jan de Mooij [:jandem]]

Attachment: Bug 1893554 - Ensure Ion frames with rematerialized frames are invalidated. r?iain!

When the debugger creates a RematerializedFrame for an Ion frame, we need to invalidate
the Ion frame to ensure the rematerialized frame is destroyed in FinishBailoutToBaseline
(or the exception handler).

The debugger code could fail with OOM before doing this invalidation and in this case we
left a rematerialized frame in the activation's map after returning from the Ion frame.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a7ff2aad84a1
Ensure Ion frames with rematerialized frames are invalidated. r=iain

Comment 8

[Sandor Molnar[:smolnar]]

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