function g(x, y) {
  Math.hypot(
    Math.cos(Math.round(Math.max) | 0) + y ==
      Math.round(
        Math.min(Math.fround(Math.atan2(Math.round(), Math.round()) >> 0))
      ),
    Math.tan(Math.cbrt(!y > 0)) | 0
  ) /
    Math.cos(Math.fround(Math.round() + Math.fround(-+(y > x)))) >
    0;
}
for (let j = 0; j < 9; j++) {
  for (let k = 0; k < 9; k++) {
    (function (x) {
      (Math.round(
        Math.hypot(Math.fround(Math.exp(Math.atan2(Math.max()) > 0)) > 0) *
          Math.pow(-x)
      ) >
        Math.sin()) |
        Math.round(
          Math.max(
            Math.fround(
              Math.min(
                !x * g() ? h.f : ~g,
                x >
                  Math.sin(
                    Math.min(x, Math.round()),
                    Math.round(Math.imul(Math.tan() > 0) | 0, x | 0) *
                      g(undefined, Math.log + x * x) || 0
                  )
              )
            )
          )
        );
    })();
  }
}

Thread 1 "js-dbg-64-linux" received signal SIGSEGV, Segmentation fault.
js::LifoAlloc::newChunkWithCapacity (this=this@entry=0x7ffff6c19ac0, n=<optimized out>, oversize=<optimized out>) at /home/skygentoo/trees/mozilla-central/js/src/ds/LifoAlloc.cpp:168
168	  MOZ_ASSERT(fallibleScope_,
(gdb) bt
#0  js::LifoAlloc::newChunkWithCapacity (this=this@entry=0x7ffff6c19ac0, n=<optimized out>, oversize=<optimized out>) at /home/skygentoo/trees/mozilla-central/js/src/ds/LifoAlloc.cpp:168
#1  0x000055555747227c in js::LifoAlloc::getOrCreateChunk (this=this@entry=0x7ffff6c19ac0, n=1, n@entry=232) at /home/skygentoo/trees/mozilla-central/js/src/ds/LifoAlloc.cpp:221
#2  0x000055555747243b in js::LifoAlloc::allocImplColdPath (this=0x7ffff6c19ac0, n=232) at /home/skygentoo/trees/mozilla-central/js/src/ds/LifoAlloc.cpp:231
#3  0x0000555557d3b579 in js::LifoAlloc::new_<js::jit::LIRGraph, js::jit::MIRGraph*> (this=0x7ffff7c14a00 <_IO_stdfile_2_lock>, args=<optimized out>) at /home/skygentoo/trees/mozilla-central/js/src/ds/LifoAlloc.h:1034
#4  js::jit::GenerateLIR (mir=mir@entry=0x7ffff6a5e178) at /home/skygentoo/trees/mozilla-central/js/src/jit/Ion.cpp:1411
#5  0x0000555557d3babb in js::jit::CompileBackEnd (mir=mir@entry=0x7ffff6a5e178, snapshot=snapshot@entry=0x7ffff6a63360) at /home/skygentoo/trees/mozilla-central/js/src/jit/Ion.cpp:1507
#6  0x0000555557d3cd8d in js::jit::IonCompile (cx=0x7ffff6c2d100, script=..., osrPc=<optimized out>) at /home/skygentoo/trees/mozilla-central/js/src/jit/Ion.cpp:1633
#7  js::jit::Compile (cx=cx@entry=0x7ffff6c2d100, script=script@entry=..., osrFrame=osrFrame@entry=0x7fffffffb678, osrPc=osrPc@entry=0x0) at /home/skygentoo/trees/mozilla-central/js/src/jit/Ion.cpp:1800
#8  0x0000555557d3d93f in BaselineCanEnterAtEntry (cx=0x7ffff6c2d100, script=..., frame=0x7fffffffb678) at /home/skygentoo/trees/mozilla-central/js/src/jit/Ion.cpp:1932
#9  IonCompileScriptForBaseline (cx=0x7ffff6c2d100, frame=0x7fffffffb678, pc=0x7ffff6acb221 "\264\001") at /home/skygentoo/trees/mozilla-central/js/src/jit/Ion.cpp:2056
#10 0x00003f35c67433b6 in ?? ()
#11 0x0000000000ff0000 in ?? ()
#12 0x00007fffffffb650 in ?? ()
#13 0x0000555558569be0 in js::jit::vmFunctions ()
#14 0x00007fffffffb6c0 in ?? ()
#15 0x00003f35c6780bdc in ?? ()
#16 0x0000000000000001 in ?? ()
#17 0x00007fffffffb678 in ?? ()
#18 0x0000000000000000 in ?? ()
(gdb)

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/869a971a4902
user:        André Bargull
date:        Wed Jan 18 18:35:00 2023 +0000
summary:     Bug 1810299 - Part 3: Remove extra CacheIR code for relational comparison of Number x Undefined. r=jandem

Run with --fuzzing-safe --no-threads --ion-gvn=off --fast-warmup, compile with AR=ar sh ../configure --enable-debug --with-ccache --enable-nspr-build --enable-ctypes --enable-debug-symbols --enable-gczeal --enable-rust-simd --disable-tests, tested on m-c rev 869a971a4902.

:anba, is bug 1810299 a likely regressor? This seems to be a fragile testcase, fwiw. Setting s-s just-in-case.

Well actually, there's also a similar bug 1812148, but we're just within the 48-hour duplicate entry window, if it happens that way.

Set release status flags based on info from the regressing bug 1810299

(In reply to Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now) from comment #1)

Well actually, there's also a similar bug 1812148, but we're just within the 48-hour duplicate entry window, if it happens that way.

Both bugs are collisions, we have both of these in our internal system since 1/19/2023 14:11 (and 1/19/2023 14:54 for bug 1812148 respectively).

Since these are low priority and not s-s usually, we are focusing on other bugs which is why these are not filed yet.

:anba, is bug 1810299 a likely regressor? This seems to be a fragile testcase, fwiw.

I can't reproduce the failure locally, but it's probably the same issue as bug 1812148. If it's the same issue as bug 1812148, then the actual regressor is bug 1791520 (specifically it's this commit: https://hg.mozilla.org/mozilla-central/rev/b7c6834859a4).

This is not the same bugs, but the same symptoms. One being under OptimizeMIR and the other under OptimizeLIR.

However, the assertions is eagerly forcing an OOM in debug builds, whereas a release build would actually have to exhaust memory before reproducing this issue.

I just rechecked - https://hg.mozilla.org/mozilla-central/rev/b0681205064c may have fixed this. Andre, is bug 1811264 a likely fix?

Bug 1811264 added optimisations for more types in relational comparison, which means some operations no longer end up calling into the VM and therefore it's no longer necessary to emit MKeepAliveObject.

I've rechecked with the exact commit https://hg.mozilla.org/mozilla-central/rev/869a971a4902 and could finally reproduce the assertion error. Then I've applied the fix from bug 1812148 and verified the assertion error is no longer triggered. So this is indeed a dup of bug 1812148.