The following testcase crashes on mozilla-central revision 20210326-b1aad3c2a76c (debug build, run with --fuzzing-safe --ion-offthread-compile=off --ion-pruning=on --ion-warmup-threshold=0):

new Int8Array("257").sort(parseInt)

Backtrace:

received signal SIGSEGV, Segmentation fault.
#0  0x58507ca3 in js::jit::LIRGeneratorShared::use(js::jit::MDefinition*, js::jit::LUse) ()
#1  0x585b7517 in js::jit::LIRGenerator::visitBox(js::jit::MBox*) ()
#2  0x588dc1a0 in js::jit::LIRGenerator::visitInstructionDispatch(js::jit::MInstruction*) ()
#3  0x588ddf45 in js::jit::LIRGenerator::visitBlock(js::jit::MBasicBlock*) ()
#4  0x588de1b3 in js::jit::LIRGenerator::generate() ()
#5  0x587904f3 in js::jit::GenerateLIR(js::jit::MIRGenerator*) ()
#6  0x58790ebd in js::jit::CompileBackEnd(js::jit::MIRGenerator*, js::jit::WarpSnapshot*) ()
#7  0x587926fe in js::jit::Compile(JSContext*, JS::Handle<JSScript*>, js::jit::BaselineFrame*, unsigned char*) ()
#8  0x587930dd in IonCompileScriptForBaseline(JSContext*, js::jit::BaselineFrame*, unsigned char*) ()
#9  0x58793887 in js::jit::IonCompileScriptForBaselineOSR(JSContext*, js::jit::BaselineFrame*, unsigned int, unsigned char*, js::jit::IonOsrTempData**) ()
#10 0x3d7b5b42 in ?? ()
#11 0x3d7add96 in ?? ()
eax	0x566f98cc	1450154188
ebx	0x58ee87d4	1492027348
ecx	0x58eea0d4	1492033748
edx	0x0	0
esi	0xf5ad5650	-173189552
edi	0xf5ab7d18	-173310696
ebp	0xffffa408	4294943752
esp	0xffffa3f0	4294943728
eip	0x58507ca3 <js::jit::LIRGeneratorShared::use(js::jit::MDefinition*, js::jit::LUse)+163>
=> 0x58507ca3 <_ZN2js3jit18LIRGeneratorShared3useEPNS0_11MDefinitionENS0_4LUseE+163>:	movl   $0x1b,0x0
   0x58507cad <_ZN2js3jit18LIRGeneratorShared3useEPNS0_11MDefinitionENS0_4LUseE+173>:	call   0x579a2a35 <abort>

This is explicitly disabled right now on Nightly but marking s-s for rating/triage since this is likely security-relevant.

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

Start: ea38e210ba4d6d14f40cd17fc38515ce7e965e60 (20210323214359)
End: 768e04aaea528ec9a0af31c49708cf73ad505a2a (20210324040732)
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ea38e210ba4d6d14f40cd17fc38515ce7e965e60&tochange=768e04aaea528ec9a0af31c49708cf73ad505a2a

Good catch.

We can open this up. The bug can only occur with branch pruning enabled, and it's still off by default.

If we specialize OSR-only phis to MIRType::Value during conversion, then it is possible for adjustPhiInputs to see a phi that is still MIRType::None. On x86, this ends up with us crashing while trying to box a Value.

It's more robust to do a separate pass at the end of phi specialization, before we start converting.

https://hg.mozilla.org/mozilla-central/rev/7c547ec195d6

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

:iain, since this bug contains a bisection range, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.