The following testcase crashes on mozilla-central revision 20220912-b66bbbcc4467 (debug build, run with --fuzzing-safe --ion-offthread-compile=off --ion-warmup-threshold=0 --baseline-eager):

function loadFile(lfVarx) {
  oomTest(function() {
    m89 = parseModule(lfVarx);
    moduleLink(m89);
    moduleEvaluate(m89)
  })
}
loadFile(`
  if (y)
    for (let x;; function() { eval() });
`);

Backtrace:

received signal SIGSEGV, Segmentation fault.
#0  0x00005555577c4a87 in js::jit::MAryInstruction<2ul>::initOperand(unsigned long, js::jit::MDefinition*) ()
#1  0x0000555557832e6f in js::jit::MAssertCanElidePostWriteBarrier* js::jit::MAssertCanElidePostWriteBarrier::New<js::jit::MNewLexicalEnvironmentObject*&, js::jit::MDefinition*&>(js::jit::TempAllocator&, js::jit::MNewLexicalEnvironmentObject*&, js::jit::MDefinition*&) ()
#2  0x0000555557829f2d in js::jit::WarpBuilder::build_FreshenLexicalEnv(js::BytecodeLocation) ()
#3  0x0000555557817c53 in js::jit::WarpBuilder::buildBody() ()
#4  0x00005555578164dd in js::jit::WarpBuilder::build() ()
#5  0x0000555557b2b6cd in js::jit::CompileBackEnd(js::jit::MIRGenerator*, js::jit::WarpSnapshot*) ()
#6  0x0000555557b2ca30 in js::jit::Compile(JSContext*, JS::Handle<JSScript*>, js::jit::BaselineFrame*, unsigned char*) ()
#7  0x0000555557b2be47 in js::jit::CanEnterIon(JSContext*, js::RunState&) ()
#8  0x0000555557b6819c in js::jit::MaybeEnterJit(JSContext*, js::RunState&) ()
#9  0x0000555556d3407a in js::RunScript(JSContext*, js::RunState&) ()
#10 0x0000555556d49874 in js::ExecuteKernel(JSContext*, JS::Handle<JSScript*>, JS::Handle<JSObject*>, js::AbstractFramePtr, JS::MutableHandle<JS::Value>) ()
#11 0x0000555556d49dc1 in js::Execute(JSContext*, JS::Handle<JSScript*>, JS::Handle<JSObject*>, JS::MutableHandle<JS::Value>) ()
#12 0x0000555556dd637a in js::ModuleObject::execute(JSContext*, JS::Handle<js::ModuleObject*>) ()
#13 0x0000555556f94855 in InnerModuleEvaluation(JSContext*, JS::Handle<js::ModuleObject*>, JS::MutableHandle<JS::GCVector<js::ModuleObject*, 0ul, js::SystemAllocPolicy> >, unsigned long, unsigned long*) ()
#14 0x0000555556f8d71e in js::ModuleEvaluate(JSContext*, JS::Handle<js::ModuleObject*>, JS::MutableHandle<JS::Value>) ()
#15 0x0000555556bd4644 in ModuleEvaluate(JSContext*, unsigned int, JS::Value*) ()
#16 0x00000e9193e472ee in ?? ()
[...]
#19 0x0000000000000000 in ?? ()
rax	0x55555574abbd	93824994290621
rbx	0x7ffff484d2e8	140737295733480
rcx	0x5555582cdae8	93825039915752
rdx	0x0	0
rsi	0x7ffff7105770	140737338431344
rdi	0x7ffff7104540	140737338426688
rbp	0x7fffffff9a20	140737488329248
rsp	0x7fffffff9a20	140737488329248
r8	0x7ffff7105770	140737338431344
r9	0x7ffff7f99800	140737353717760
r10	0x0	0
r11	0x0	0
r12	0x7ffff484d1d8	140737295733208
r13	0x7fffffff9ca0	140737488329888
r14	0x0	0
r15	0x7fffffff9ae0	140737488329440
rip	0x5555577c4a87 <js::jit::MAryInstruction<2ul>::initOperand(unsigned long, js::jit::MDefinition*)+263>
=> 0x5555577c4a87 <_ZN2js3jit15MAryInstructionILm2EE11initOperandEmPNS0_11MDefinitionE+263>:	movl   $0xd1,0x0
   0x5555577c4a92 <_ZN2js3jit15MAryInstructionILm2EE11initOperandEmPNS0_11MDefinitionE+274>:	callq  0x555556c349f4 <abort>

Probably introduced by bug 1341937, so I'll take a look.

Bugmon Analysis
Verified bug as reproducible on mozilla-central 20220919105141-d42e0ca4bb3e.
The bug appears to have been introduced in the following build range:

Start: efabaf7b335b5ccd97d3b5b810169f1ed4af64d4 (20220908144118)
End: 5da07fdf2c5ebfed80d13cb3321ad39b7f56b075 (20220908144305)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=efabaf7b335b5ccd97d3b5b810169f1ed4af64d4&tochange=5da07fdf2c5ebfed80d13cb3321ad39b7f56b075

Setting Regressed by field after analyzing regression range found by bugmon in comment #5.

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

https://hg.mozilla.org/mozilla-central/rev/665731c8f749

Do we want to uplift this patch the 106 beta? Thanks

Bugmon Analysis
Verified bug as fixed on rev mozilla-central 20220921035608-fb7ca98a6881.
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.

Comment on attachment 9295293 [details]
Bug 1791401: Handle OOM after calling WarpBuilder::walkEnvironmentChain. r=jandem!

Beta/Release Uplift Approval Request

• User impact if declined: Possible null-pointer crash when creating the MIR graph for JIT compilation.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): A trivial, non-risky change which simply checks when an allocation has failed.
• String changes made/needed:
• Is Android affected?: Yes

(In reply to Pascal Chevrel:pascalc from comment #10)

Do we want to uplift this patch the 106 beta? Thanks

Sure, it's a trivial change, so it's safe to uplift directly.

Comment on attachment 9295293 [details]
Bug 1791401: Handle OOM after calling WarpBuilder::walkEnvironmentChain. r=jandem!

Approved for 106.0b3, thanks.

https://hg.mozilla.org/releases/mozilla-beta/rev/d0dc2d7d0ef7

Hello, André!
Is manual QA testing needed here? Is something that QA should check manually here?
Thanks!

(In reply to Camelia Badau [:cbadau], Release Desktop QA from comment #17)

Hello, André!
Is manual QA testing needed here? Is something that QA should check manually here?
Thanks!

No, manual testing isn't needed. Just liked in bug 1791352, it appears I was in auto-pilot mode and just clicked through the "Yes" buttons. Sorry for the inconvenience!