1900463 - Assertion failure: forIns->bailoutKind() != BailoutKind::TranspiledCacheIR, at jit/TypePolicy.cpp:60

Status: RESOLVED WORKSFORME

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

Description

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

oomTest(function () {
  var x = "a"[0];
  var y = "abc"[2];
  let [, , ...z] = "abcd";
  try {
    ""();
  } catch {}
  t = [];
  m = [](0, ..."abcde");
});

60        MOZ_ASSERT(forIns->bailoutKind() != BailoutKind::TranspiledCacheIR);
(gdb) bt
#0  SetTypePolicyBailoutKind (newIns=0x7ffff4ceecf8, forIns=0x7ffff4cc6858) at /home/yksubu/trees/mozilla-central/js/src/jit/TypePolicy.cpp:60
#1  js::jit::ArithPolicy::adjustInputs (this=<optimized out>, alloc=..., ins=0x7ffff4cc6858) at /home/yksubu/trees/mozilla-central/js/src/jit/TypePolicy.cpp:135
#2  0x00005555583bd88e in (anonymous namespace)::TypeAnalyzer::adjustInputs (this=0x7ffff65fe500, def=0x7ffff4cc6858) at /home/yksubu/trees/mozilla-central/js/src/jit/IonAnalysis.cpp:2316
#3  (anonymous namespace)::TypeAnalyzer::insertConversions (this=0x7ffff65fe500) at /home/yksubu/trees/mozilla-central/js/src/jit/IonAnalysis.cpp:2401
#4  (anonymous namespace)::TypeAnalyzer::analyze (this=this@entry=0x7ffff65fe500) at /home/yksubu/trees/mozilla-central/js/src/jit/IonAnalysis.cpp:2912
#5  0x00005555583b220e in js::jit::ApplyTypeInformation (mir=mir@entry=0x7ffff4c83180, graph=...) at /home/yksubu/trees/mozilla-central/js/src/jit/IonAnalysis.cpp:2924
#6  0x00005555583a9ea2 in js::jit::OptimizeMIR (mir=mir@entry=0x7ffff4c83180) at /home/yksubu/trees/mozilla-central/js/src/jit/Ion.cpp:1150
#7  0x00005555583b6645 in js::jit::CompileBackEnd (mir=0x7ffff4c83180, snapshot=<optimized out>) at /home/yksubu/trees/mozilla-central/js/src/jit/Ion.cpp:1631
#8  0x00005555583daba2 in js::jit::IonCompileTask::runTask (this=0x7ffff4c87128) at /home/yksubu/trees/mozilla-central/js/src/jit/IonCompileTask.cpp:52
#9  js::jit::IonCompileTask::runHelperThreadTask (this=0x7ffff4c87128, locked=...) at /home/yksubu/trees/mozilla-central/js/src/jit/IonCompileTask.cpp:30
#10 0x00005555574b5cb0 in js::GlobalHelperThreadState::runTaskLocked (this=0x7ffff661b000, task=0x7ffff4c87128, locked=...) at /home/yksubu/trees/mozilla-central/js/src/vm/HelperThreads.cpp:1735
#11 0x00005555574b5b44 in js::GlobalHelperThreadState::runOneTask (this=0x7ffff7a1ca60 <_IO_stdfile_2_lock>, task=0x0, lock=...) at /home/yksubu/trees/mozilla-central/js/src/vm/HelperThreads.cpp:1691
#12 0x00005555574dd671 in js::HelperThread::threadLoop (this=this@entry=0x7ffff660dba0, pool=pool@entry=0x7ffff660f100) at /home/yksubu/trees/mozilla-central/js/src/vm/InternalThreadPool.cpp:324
#13 0x00005555574dd3fc in js::HelperThread::ThreadMain (pool=0x7ffff660f100, helper=0x7ffff660dba0) at /home/yksubu/trees/mozilla-central/js/src/vm/InternalThreadPool.cpp:251
#14 0x00005555574f42a8 in js::detail::ThreadTrampoline<void (&)(js::InternalThreadPool*, js::HelperThread*), js::InternalThreadPool*&, js::HelperThread*>::callMain<0ul, 1ul> (this=0x7ffff660d900) at /home/yksubu/trees/mozilla-central/js/src/threading/Thread.h:228
#15 js::detail::ThreadTrampoline<void (&)(js::InternalThreadPool*, js::HelperThread*), js::InternalThreadPool*&, js::HelperThread*>::Start (aPack=0x7ffff660d900) at /home/yksubu/trees/mozilla-central/js/src/threading/Thread.h:217
#16 0x00007ffff7894ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#17 0x00007ffff7926850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb)

Run with --fuzzing-safe --fast-warmup --inlining-entry-threshold=16 --ion-warmup-threshold=0 --monomorphic-inlining=never, 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 709248f1fc69.

Still bisecting, perhaps it's related to disabling monomorphic inlining.

Setting s-s to be safe, though I think this may just be a optimization/perf issue. Iain, do you mind taking a look?

Comment 1

[Iain Ireland [:iain]]

This looks very similar to bug 1892184. We're inlining self-hosted string iteration code that uses UnsafeGetInt32FromReservedSlot to avoid unnecessary type guards when incrementing the index. A precisely timed OOM causes us to compile without any IC for a JSOp::Add. After some optimization, we end up with a Value-typed input to an Int32 MAdd, which asserts in type policy code that is otherwise almost entirely dead. This is spurious: the value in question will always be an Int32.

The assertion that's failing is intended to catch performance issues, not correctness/security concerns, so this isn't security sensitive.

I'm not immediately sure what the best fix for this is. It's not particularly urgent to fix, since it's a debug-only assertion that is safe to ignore in release builds and can only be triggered with a single laser-guided OOM, which basically can't happen in the real world. I'm tempted to reuse the approach that we took for bailout loop detection (don't bother with performance asserts if we've ever triggered OOM / stack overflow), although it might be a bit awkward since we're doing the Ion compilation off-thread and don't have access to the context.

Comment 2

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

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/c62a7e2f6607
user:        Jan de Mooij
date:        Wed Jan 17 14:10:54 2024 +0000
summary:     Bug 1873027 - Add a shell flag to override use of monomorphic inlining. r=iain

I'm not sure if this is the real regressor though. It may have just enabled this bug to show up.

Comment 3

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

The first good revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/31a6e5abd49b
user:        Jan de Mooij
date:        Mon Feb 03 14:31:22 2025 +0000
summary:     Bug 1944843 part 2 - Use GuardToInt32 instead of GuardToInt32Index for int32 values. r=iain

Jan, did bug 1944843 fix this bug? Or is it a red herring?

Comment 4

[Iain Ireland [:iain]]

I revisited this briefly. Jan's code does kick in here to generate slightly different MIR in the vicinity of where the bug was taking place, in a way that could plausibly eliminate the bug.

Given that this bug wasn't really worth spending time fixing (the only effect is a slight performance regression in a pathological case, and it requires a tactical OOM that is probably impossible in the real world) I think it's fine to just mark it as WORKSFORME.

Comment 5

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

Thanks Iain!