The following testcase crashes on mozilla-central revision 20230329-ff84e2935cc3 (opt build, run with --fuzzing-safe --ion-offthread-compile=off --ion-gvn=off --fast-warmup):

typedArrayConstructors = Object([ Int8Array, Uint8Array, Uint8ClampedArray ]);
anyTypedArrayConstructors = Object([ ...typedArrayConstructors ]);
for (constructor of anyTypedArrayConstructors) {
  [undefined, null, 1, false, "", Symbol, [], {}, /./, ({})].forEach(invalidReceiver => {
    try {
      (() => {
        constructor.prototype.lastIndexOf()
      })()
    } catch(exc) {}
  });
  new constructor([10]).lastIndexOf(10, undefined)
}

Backtrace:

received signal SIGSEGV, Segmentation fault.
#0  0x00005555559f55c6 in void js::jit::CodeGenerator::emitGetInlinedArgument<js::jit::LGetInlinedArgument>(js::jit::LGetInlinedArgument*, js::jit::Register, js::jit::ValueOperand) ()
#1  0x0000555555f987ac in js::jit::CodeGenerator::generateBody() ()
#2  0x0000555556300192 in js::jit::CodeGenerator::generate() ()
#3  0x0000555556310bb9 in js::jit::CompileBackEnd(js::jit::MIRGenerator*, js::jit::WarpSnapshot*) ()
#4  0x0000555556311836 in js::jit::Compile(JSContext*, JS::Handle<JSScript*>, js::jit::BaselineFrame*, unsigned char*) [clone .llvm.1517043733001563898] ()
#5  0x0000555556311d59 in js::jit::IonCompileScriptForBaselineAtEntry(JSContext*, js::jit::BaselineFrame*) ()
#6  0x00002395f2886ffe in ?? ()
[...]
#16 0x0000000000000000 in ?? ()
rax	0x3c	60
rbx	0x7ffff6068830	140737321011248
rcx	0x1	1
rdx	0x7fffffff	2147483647
rsi	0x2	2
rdi	0x7ffff6022c18	140737320725528
rbp	0x7fffffffb6e0	140737488336608
rsp	0x7fffffffb660	140737488336480
r8	0xffffffff	4294967295
r9	0x317	791
r10	0x317	791
r11	0xffffffffffffffff	-1
r12	0x1	1
r13	0x7fffffffb690	140737488336528
r14	0x50	80
r15	0x7ffff6022c00	140737320725504
rip	0x5555559f55c6 <void js::jit::CodeGenerator::emitGetInlinedArgument<js::jit::LGetInlinedArgument>(js::jit::LGetInlinedArgument*, js::jit::Register, js::jit::ValueOperand)+118>
=> 0x5555559f55c6 <_ZN2js3jit13CodeGenerator22emitGetInlinedArgumentINS0_19LGetInlinedArgumentEEEvPT_NS0_8RegisterENS0_12ValueOperandE+118>:	movzbl 0x41(%rax),%edx
   0x5555559f55ca <_ZN2js3jit13CodeGenerator22emitGetInlinedArgumentINS0_19LGetInlinedArgumentEEEvPT_NS0_8RegisterENS0_12ValueOperandE+122>:	mov    %rbx,%rdi

S-s due to dangerous-looking assertion and non-zero crash involving low-level JIT code.

Also causes this use-after-poison:

==243112==ERROR: AddressSanitizer: use-after-poison on address 0x631000090b30 at pc 0x55d15e6ac2d5 bp 0x7ffe9d83c500 sp 0x7ffe9d83c4f8
READ of size 8 at 0x631000090b30 thread T0
    #0 0x55d15e6ac2d4 in kind js/src/jit/LIR.h:146:38
    #1 0x55d15e6ac2d4 in isConstantValue js/src/jit/LIR.h:151:41
    #2 0x55d15e6ac2d4 in isConstant js/src/jit/LIR.h:150:36
    #3 0x55d15e6ac2d4 in js::jit::CodeGenerator::toConstantOrRegister(js::jit::LInstruction*, unsigned long, js::jit::MIRType) js/src/jit/CodeGenerator.cpp:14080:14
    #4 0x55d15e6ac509 in void js::jit::CodeGenerator::emitGetInlinedArgument<js::jit::LGetInlinedArgument>(js::jit::LGetInlinedArgument*, js::jit::Register, js::jit::ValueOperand) js/src/jit/CodeGenerator.cpp:7603:30
    #5 0x55d15e6481ed in js::jit::CodeGenerator::generateBody() js/src/jit/CodeGenerator.cpp:6724:9
    #6 0x55d15e6c27c7 in js::jit::CodeGenerator::generate() js/src/jit/CodeGenerator.cpp:13390:8
    #7 0x55d15e70f26c in js::jit::GenerateCode(js::jit::MIRGenerator*, js::jit::LIRGraph*) js/src/jit/Ion.cpp:1513:17
    #8 0x55d15e70f51a in js::jit::CompileBackEnd(js::jit::MIRGenerator*, js::jit::WarpSnapshot*) js/src/jit/Ion.cpp:1542:10
    #9 0x55d15e711644 in IonCompile js/src/jit/Ion.cpp:1663:38
    #10 0x55d15e711644 in js::jit::Compile(JSContext*, JS::Handle<JSScript*>, js::jit::BaselineFrame*, unsigned char*) js/src/jit/Ion.cpp:1830:24
    #11 0x55d15e7121c2 in BaselineCanEnterAtEntry js/src/jit/Ion.cpp:1962:25
    #12 0x55d15e7121c2 in IonCompileScriptForBaseline(JSContext*, js::jit::BaselineFrame*, unsigned char*) js/src/jit/Ion.cpp:2086:12

I'm betting this is a regression from bug 1819722, which was recently backed out for causing a Nightly crash spike as well. Christian, does this still reproduce on m-c tip?

Testcase crashes using the initial build (mozilla-central 20230329030858-ff84e2935cc3) but not with tip (mozilla-central 20230329095653-45fc9bb4de9c.)

The bug appears to have been fixed in the following build range:

Start: 429f4ff8576a623e52b5d782db76f4b898009ce4 (20230329073718)
End: 45fc9bb4de9c9d7d5b9933977891a99d10e47d6e (20230329095653)
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=429f4ff8576a623e52b5d782db76f4b898009ce4&tochange=45fc9bb4de9c9d7d5b9933977891a99d10e47d6e

Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.

(In reply to Ryan VanderMeulen [:RyanVM] from comment #4)

I'm betting this is a regression from bug 1819722, which was recently backed out for causing a Nightly crash spike as well. Christian, does this still reproduce on m-c tip?

I cannot reproduce with this exact testcase (as indicated by comment 5), but I am seeing the same assertion again on tip. Working on a test now.

:dthayer, since you are the author of the regressor, bug 1819722, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

This is an automated crash issue comment:

Summary: Assertion failure: numActuals > 0 && numActuals <= ArgumentsObject::MaxInlinedArgs, at jit/CodeGenerator.cpp:7597
Build version: mozilla-central revision 20230331-f55cea6faa5f
Build type: debug
Runtime options: --fuzzing-safe --fast-warmup --blinterp --blinterp-warmup-threshold=1 --more-compartments --baseline-warmup-threshold=0 --ion-pruning=off

Testcase:

function testMathyFunction (f, inputs) {
  for (var j = 0; j < inputs.length; ++j)
    for (var k = 0; k < inputs.length; ++k)
      try {
        f(inputs[j], inputs[k])
      } catch (e) {}
}
mathy4=(function(ff){
  function f(){ ff(); }
  return f
})(Date.prototype.toLocaleString);
testMathyFunction(mathy4, [
  new Number(),new Number(),new Number(),new Number(),
  new Number(),new Number(),new Number(),new Number(),
  new Number(),new Number()
])

Backtrace:

received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff520d700 (LWP 8873)]
0x0000555557b0e833 in void js::jit::CodeGenerator::emitGetInlinedArgument<js::jit::LGetInlinedArgument>(js::jit::LGetInlinedArgument*, js::jit::Register, js::jit::ValueOperand) ()
#0  0x0000555557b0e833 in void js::jit::CodeGenerator::emitGetInlinedArgument<js::jit::LGetInlinedArgument>(js::jit::LGetInlinedArgument*, js::jit::Register, js::jit::ValueOperand) ()
#1  0x0000555557ac7f57 in js::jit::CodeGenerator::generateBody() ()
#2  0x0000555557b1ce6f in js::jit::CodeGenerator::generate() ()
#3  0x0000555557b579e0 in js::jit::CompileBackEnd(js::jit::MIRGenerator*, js::jit::WarpSnapshot*) ()
#4  0x0000555557b837ee in js::jit::IonCompileTask::runHelperThreadTask(js::AutoLockHelperThreadState&) ()
#5  0x0000555556edcf37 in js::GlobalHelperThreadState::runTaskLocked(js::HelperThreadTask*, js::AutoLockHelperThreadState&) ()
#6  0x0000555556edcce0 in js::GlobalHelperThreadState::runOneTask(js::AutoLockHelperThreadState&) ()
#7  0x0000555556eef8e2 in js::HelperThread::threadLoop(js::InternalThreadPool*) ()
#8  0x0000555556eef69c in js::HelperThread::ThreadMain(js::InternalThreadPool*, js::HelperThread*) ()
#9  0x0000555556efd7f8 in js::detail::ThreadTrampoline<void (&)(js::InternalThreadPool*, js::HelperThread*), js::InternalThreadPool*&, js::HelperThread*>::Start(void*) ()
#10 0x00007ffff7bc16ba in start_thread (arg=0x7ffff520d700) at pthread_create.c:333
#11 0x00007ffff6e4641d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
rax	0x5555557971a3	93824994603427
rbx	0xffffffff	4294967295
rcx	0x5555582f7a98	93825040087704
rdx	0x0	0
rsi	0x7ffff7105770	140737338431344
rdi	0x7ffff7104540	140737338426688
rbp	0x7ffff520c730	140737305954096
rsp	0x7ffff520c6a0	140737305953952
r8	0x7ffff7105770	140737338431344
r9	0x7ffff520d700	140737305958144
r10	0x0	0
r11	0x0	0
r12	0x7ffff60556c0	140737320933056
r13	0x7ffff480f400	140737295479808
r14	0x0	0
r15	0x7ffff60556d8	140737320933080
rip	0x555557b0e833 <void js::jit::CodeGenerator::emitGetInlinedArgument<js::jit::LGetInlinedArgument>(js::jit::LGetInlinedArgument*, js::jit::Register, js::jit::ValueOperand)+1203>
=> 0x555557b0e833 <_ZN2js3jit13CodeGenerator22emitGetInlinedArgumentINS0_19LGetInlinedArgumentEEEvPT_NS0_8RegisterENS0_12ValueOperandE+1203>:	movl   $0x1dad,0x0
   0x555557b0e83e <_ZN2js3jit13CodeGenerator22emitGetInlinedArgumentINS0_19LGetInlinedArgumentEEEvPT_NS0_8RegisterENS0_12ValueOperandE+1214>:	callq  0x555556c24274 <abort>

Also crashes opt builds in similar ways than comment 0.

Funny story: the recurring assertion is actually unrelated to Doug's patch. It's actually triggered by Jan's patches in bug 1825014. Here's a simpler testcase (run with --ion-pruning=off --fast-warmup):

function foo() {
    Date.prototype.toLocaleString()
}

for (var i = 0; i < 100; i++) {
    try {
	foo();
    } catch {}
}

The problem is this code in Date_toLocaleString:

  var locales = ArgumentsLength() ? GetArgument(0) : undefined;
  var options = ArgumentsLength() > 1 ? GetArgument(1) : undefined;

If we inline this at a call site with no arguments, and turn off branch pruning, then we will generate an unreachable GetInlinedArgument with index greater than the number of actual arguments. In Doug's case we were doing this because we were sharing CacheIR with another caller that passed more arguments. In this case, we're hardcoding the GetInlinedArgument.

Doug was originally leaning towards fixing this by turning off monomorphic inlining of scripts that use the arguments object, but I think this second version of the bug makes the case that we should just fix GetInlinedArgument (probably by having it generate assumeUnreachable).

This is not s-s. We always crash safely during Ion codegen.

https://hg.mozilla.org/mozilla-central/rev/2ce0bfc8f05b