1429031 - Hit MOZ_CRASH(unexpected type) at js/src/jit/LIR.h:635 with ES6 modules

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision ca379fcca95b (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-profiling --enable-debug --enable-optimize, run with --fuzzing-safe --ion-offthread-compile=off --ion-eager):

let moduleRepo = {};
setModuleResolveHook(function(module, specifier) {
    return moduleRepo[specifier];
});
assertEq = function(a, b) {}
evaluate(`
let a = moduleRepo['a'] = parseModule(
    'export var a = 1;'
);
let b = moduleRepo['b'] = parseModule(
    \`import * as ns from 'a';
     export var x = ns.a + ns.b;\`
);
b.declarationInstantiation();
let ns = getModuleEnvironmentValue(b, "ns");
assertEq(ns.a, 1);
while ( t.ArrayType() ) 1;    
`);


Backtrace:

received signal SIGSEGV, Segmentation fault.
0x00000000007f8828 in js::jit::LDefinition::TypeFrom (type=<optimized out>) at js/src/jit/LIR.h:635
#0  0x00000000007f8828 in js::jit::LDefinition::TypeFrom (type=<optimized out>) at js/src/jit/LIR.h:635
#1  0x00000000007a0bb2 in js::jit::LIRGeneratorShared::define<0ul> (this=0x7fffffffa0c0, lir=0x7ffff439ac40, mir=0x7ffff4378880, policy=js::jit::LDefinition::REGISTER) at js/src/jit/shared/Lowering-shared-inl.h:45
#2  0x00000000007ae229 in js::jit::LIRGenerator::visitInstruction (this=this@entry=0x7fffffffa0c0, ins=ins@entry=0x7ffff4378880) at js/src/jit/Lowering.cpp:5080
#3  0x00000000007ca8d6 in js::jit::LIRGenerator::visitInstruction (ins=0x7ffff4378880, this=0x7fffffffa0c0) at js/src/jit/Lowering.cpp:5078
#4  js::jit::LIRGenerator::visitBlock (this=0x7fffffffa0c0, block=0x7ffff4374768) at js/src/jit/Lowering.cpp:5162
#5  0x00000000007cac0b in js::jit::LIRGenerator::generate (this=this@entry=0x7fffffffa0c0) at js/src/jit/Lowering.cpp:5230
#6  0x0000000000728ffb in js::jit::GenerateLIR (mir=mir@entry=0x7ffff4374270) at js/src/jit/Ion.cpp:1888
#7  0x000000000074e4f5 in js::jit::CompileBackEnd (mir=mir@entry=0x7ffff4374270) at js/src/jit/Ion.cpp:1983
#8  0x000000000043439b in js::jit::IonCompile (cx=cx@entry=0x7ffff5f16000, script=<optimized out>, baselineFrame=baselineFrame@entry=0x7fffffffb528, osrPc=osrPc@entry=0x7ffff4010852 "ず\n", recompile=<optimized out>, optimizationLevel=<optimized out>) at js/src/jit/Ion.cpp:2270
#9  0x000000000074eac8 in js::jit::Compile (cx=cx@entry=0x7ffff5f16000, script=script@entry=..., osrFrame=osrFrame@entry=0x7fffffffb528, osrPc=osrPc@entry=0x7ffff4010852 "ず\n", forceRecompile=<optimized out>) at js/src/jit/Ion.cpp:2462
#10 0x000000000074f288 in BaselineCanEnterAtBranch (pc=0x7ffff4010852 "ず\n", osrFrame=0x7fffffffb528, script=..., cx=0x7ffff5f16000) at js/src/jit/Ion.cpp:2639
#11 js::jit::IonCompileScriptForBaseline (cx=0x7ffff5f16000, frame=frame@entry=0x7fffffffb528, pc=pc@entry=0x7ffff4010852 "ず\n") at js/src/jit/Ion.cpp:2697
#12 0x0000000000635f02 in js::jit::DoWarmUpCounterFallbackOSR (cx=0x7ffff5f16000, frame=0x7fffffffb528, stub=0x7ffff4153490, infoPtr=0x7fffffffb500) at js/src/jit/BaselineIC.cpp:146
#13 0x00001d20b8e56a59 in ?? ()
[...]
#22 0x0000000000000000 in ?? ()
rax	0x0	0
rbx	0x7ffff439ac40	140737290808384
rcx	0x7ffff6c282ad	140737333330605
rdx	0x0	0
rsi	0x7ffff6ef7770	140737336276848
rdi	0x7ffff6ef6540	140737336272192
rbp	0x7fffffff9f40	140737488330560
rsp	0x7fffffff9f40	140737488330560
r8	0x7ffff6ef7770	140737336276848
r9	0x7ffff7fe4780	140737354024832
r10	0x58	88
r11	0x7ffff6b9e7a0	140737332766624
r12	0x7fffffffa0c0	140737488330944
r13	0x7fffffffa0c0	140737488330944
r14	0x7ffff4378880	140737290668160
r15	0x7ffff43788d0	140737290668240
rip	0x7f8828 <js::jit::LDefinition::TypeFrom(js::jit::MIRType)+216>
=> 0x7f8828 <js::jit::LDefinition::TypeFrom(js::jit::MIRType)+216>:	movl   $0x0,0x0
   0x7f8833 <js::jit::LDefinition::TypeFrom(js::jit::MIRType)+227>:	ud2

Comment 1

[Jon Coppeard (:jonco)]

Attachment: bug1429031-load-namespace-slot

LDefinition::TypeFrom is asserting because the result type for an MLoadFixedSlot is Undefined.  This comes from the call to loadSlot() in IonBuilder::getPropTryModuleNamespace here:

https://searchfox.org/mozilla-central/source/js/src/jit/IonBuilder.cpp#10845

By looking at other places where this happens it seems I have to check the result of types->getKnownMIRType() before passing it to loadSlot().  I don't really understand what this is doing, but it does fix the problem.

Jan, is the the right thing to do?  As far as I know the result will always be a value here, but I don't want to preclude any optimisations that Ion might be able to do.

Comment 2

[Jan de Mooij [:jandem]]

Comment on attachment 8941378 [details] [diff] [review]
bug1429031-load-namespace-slot

Review of attachment 8941378 [details] [diff] [review]:
-----------------------------------------------------------------

Yeah this makes sense. The problem is that we can't do a typed load of MIRType::Undefined or MIRType::Null, because there's no payload to load. IIRC we have code elsewhere to add an undefined/null constant in this case.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/d055b4f81d59
Fix an assertion failure while optimising a module namespace access r=jandem

Comment 4

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/d055b4f81d59