Crash [@ EmitUnarySimd128] or Assertion failure: producer_ != nullptr, at it/MIR.h:248
Categories
(Core :: JavaScript Engine: JIT, defect, P2)
Tracking
()
People
(Reporter: gkw, Assigned: yury)
References
(Blocks 2 open bugs)
Details
(Keywords: reporter-external, testcase)
Attachments
(1 file)
oomTest(function () {
let x = new Uint8Array([0,97,115,109,1,0,0,0,1,4,1,96,0,0,3,2,1,0,5,4,1,1,0,0,7,10,1,6,109,101,109,111,114,121,2,0,10,49,1,47,0,65,16,253,1,1,1,253,-128,1,253,131,1,65,158,232,68,253,1,1,1,253,100,65,16,253,1,1,1,253,11,0,0,253,1,1,1,65,158,232,68,253,1,1,0,0,11,0,14,4,110,97,109,101,1,7,1,0,4,109,97,105,110]);
new WebAssembly.Module(x);
});
(gdb) bt
#0 EmitUnarySimd128 (f=..., op=js::wasm::SimdOp::I16x8Abs) at /home/gen32gx500/trees/mozilla-central/js/src/wasm/WasmIonCompile.cpp:7096
#1 0x000055555858090e in EmitBodyExprs (f=...) at /home/gen32gx500/trees/mozilla-central/js/src/wasm/WasmIonCompile.cpp:8845
#2 0x000055555857e3ab in js::wasm::IonCompileFunctions (moduleEnv=..., compilerEnv=..., lifo=..., inputs=..., code=0x7ffff66c33b0, error=error@entry=0x7fffffffbe80)
at /home/gen32gx500/trees/mozilla-central/js/src/wasm/WasmIonCompile.cpp:9406
#3 0x000055555855d96b in ExecuteCompileTask (task=0x7ffff66c3000, error=0x7fffffffbe80) at /home/gen32gx500/trees/mozilla-central/js/src/wasm/WasmGenerator.cpp:729
#4 0x000055555855e717 in js::wasm::ModuleGenerator::locallyCompileCurrentTask (this=0x7fffffffae50)
at /home/gen32gx500/trees/mozilla-central/js/src/wasm/WasmGenerator.cpp:784
#5 js::wasm::ModuleGenerator::finishFuncDefs (this=0x7fffffffae50) at /home/gen32gx500/trees/mozilla-central/js/src/wasm/WasmGenerator.cpp:915
#6 0x0000555558533281 in DecodeCodeSection<js::wasm::Decoder> (env=..., d=..., mg=...) at /home/gen32gx500/trees/mozilla-central/js/src/wasm/WasmCompile.cpp:785
#7 0x0000555558532f5f in js::wasm::CompileBuffer (args=..., bytecode=..., error=error@entry=0x7fffffffbe80, warnings=warnings@entry=0x7fffffffbea8,
listener=listener@entry=0x0) at /home/gen32gx500/trees/mozilla-central/js/src/wasm/WasmCompile.cpp:807
#8 0x000055555858cc35 in js::WasmModuleObject::construct (cx=0x7ffff6630800, argc=<optimized out>, vp=<optimized out>)
at /home/gen32gx500/trees/mozilla-central/js/src/wasm/WasmJS.cpp:1494
#9 0x000033d7de7ce636 in ?? ()
#10 0x0000000000000008 in ?? ()
#11 0x00007fffffffbf38 in ?? ()
#12 0x00007ffff660aaea in ?? ()
#13 0x0000000000000001 in ?? ()
#14 0x00007fffffffbf88 in ?? ()
#15 0x0000000000000000 in ?? ()
(gdb)
oomTest(function () {
new WebAssembly.Module(new Uint8Array([0,97,115,109,1,0,0,0,1,4,1,96,0,0,3,2,1,0,5,4,1,1,0,0,7,10,1,6,109,101,109,111,114,121,2,0,10,49,1,47,0,65,16,253,1,1,1,253,-128,1,253,131,1,65,158,232,68,253,1,1,1,253,100,65,16,253,1,1,1,253,11,0,0,253,1,1,1,65,158,232,68,253,1,1,0,0,11,0,14,4,110,97,109,101,1,7,1,0,4,109,97,105,110]));
});
This variant above shows an assertion failure: Assertion failure: producer_ != nullptr, at <snip>jit/MIR.h:248
(gdb) bt
#0 js::jit::MUse::producer (this=<optimized out>) at /home/gen32gx500/trees/mozilla-central/js/src/jit/MIR.h:248
#1 js::jit::MDefinition::addUseUnchecked (this=0x0, use=<optimized out>) at /home/gen32gx500/trees/mozilla-central/js/src/jit/MIR.h:808
#2 js::jit::MUse::initUnchecked (this=<optimized out>, producer=0x0, consumer=0x7ffff664e8e0) at /home/gen32gx500/trees/mozilla-central/js/src/jit/MIR.h:11668
#3 js::jit::MVariadicT<js::jit::MInstruction>::initOperand (this=0x7ffff664e8e0, index=1, operand=0x0) at /home/gen32gx500/trees/mozilla-central/js/src/jit/MIR.h:1250
#4 js::jit::MWasmStore::New (alloc=..., memoryBase=memoryBase@entry=0x0, base=0x7ffff664e698, access=..., value=value@entry=0x0)
at /home/gen32gx500/trees/mozilla-central/js/src/jit/MIR.h:9691
#5 0x00005555585dcd16 in (anonymous namespace)::FunctionCompiler::store (this=0x7fffffff9320, base=0x7ffff664e698, access=0x7fffffff8f20, v=0x0)
at /home/gen32gx500/trees/mozilla-central/js/src/wasm/WasmIonCompile.cpp:1472
#6 0x00005555585af131 in EmitStore (f=..., resultType=resultType@entry=..., viewType=viewType@entry=JS::Scalar::Simd128)
at /home/gen32gx500/trees/mozilla-central/js/src/wasm/WasmIonCompile.cpp:5971
#7 0x0000555558581c8d in EmitBodyExprs (f=...) at /home/gen32gx500/trees/mozilla-central/js/src/wasm/WasmIonCompile.cpp:8661
#8 0x000055555857e3ab in js::wasm::IonCompileFunctions (moduleEnv=..., compilerEnv=..., lifo=..., inputs=..., code=0x7ffff66b83b0, error=error@entry=0x7fffffffbe90)
at /home/gen32gx500/trees/mozilla-central/js/src/wasm/WasmIonCompile.cpp:9406
#9 0x000055555855d96b in ExecuteCompileTask (task=0x7ffff66b8000, error=0x7fffffffbe90) at /home/gen32gx500/trees/mozilla-central/js/src/wasm/WasmGenerator.cpp:729
#10 0x000055555855e717 in js::wasm::ModuleGenerator::locallyCompileCurrentTask (this=0x7fffffffae60)
at /home/gen32gx500/trees/mozilla-central/js/src/wasm/WasmGenerator.cpp:784
#11 js::wasm::ModuleGenerator::finishFuncDefs (this=0x7fffffffae60) at /home/gen32gx500/trees/mozilla-central/js/src/wasm/WasmGenerator.cpp:915
#12 0x0000555558533281 in DecodeCodeSection<js::wasm::Decoder> (env=..., d=..., mg=...) at /home/gen32gx500/trees/mozilla-central/js/src/wasm/WasmCompile.cpp:785
#13 0x0000555558532f5f in js::wasm::CompileBuffer (args=..., bytecode=..., error=error@entry=0x7fffffffbe90, warnings=warnings@entry=0x7fffffffbeb8,
listener=listener@entry=0x0) at /home/gen32gx500/trees/mozilla-central/js/src/wasm/WasmCompile.cpp:807
#14 0x000055555858cc35 in js::WasmModuleObject::construct (cx=0x7ffff6635600, argc=<optimized out>, vp=<optimized out>)
at /home/gen32gx500/trees/mozilla-central/js/src/wasm/WasmJS.cpp:1494
#15 0x00000fe9b1666486 in ?? ()
#16 0x00007fffffffbf50 in ?? ()
#17 0x00007fffffffbf40 in ?? ()
#18 0x0000000000000001 in ?? ()
#19 0x00007fffffffbf90 in ?? ()
#20 0x0000000000000003 in ?? ()
#21 0x0000000000000002 in ?? ()
#22 0x0000000000000001 in ?? ()
#23 0xfffe2c89c1a65f58 in ?? ()
#24 0xfffa800000000005 in ?? ()
#25 0xfffe222cf5801c48 in ?? ()
#26 0xfffe2c89c1a65f58 in ?? ()
#27 0x00007ffff6454078 in ?? ()
#28 0x00007fffffffc010 in ?? ()
#29 0x00000fe9b164d4a0 in ?? ()
#30 0x0000000000000001 in ?? ()
#31 0xfffe2c89c1a65f58 in ?? ()
#32 0xfffe222cf5801c48 in ?? ()
#33 0xfffa800000000005 in ?? ()
#34 0xfffe2c89c1a65f58 in ?? ()
#35 0x00002c89c1a64060 in ?? ()
#36 0x00007ffff660d2f6 in ?? ()
#37 0x00007ffff6570ef0 in ?? ()
#38 0x00002c89c1a3f038 in ?? ()
#39 0x00007ffff6570e10 in ?? ()
#40 0x0000000000000000 in ?? ()
(gdb)
Run with --fuzzing-safe --no-threads --no-baseline --no-ion
, compile with AR=ar sh ../configure --enable-debug --enable-debug-symbols --with-ccache --disable-bootstrap --enable-nspr-build --enable-ctypes --enable-gczeal --enable-rust-simd --disable-tests
, tested on m-c rev 9ca12d444230.
This seems to go as far back as m-c rev a5887514ddfb (Feb 2022), and it does not occur on latest debug js shells from FTP on 2015-10-21. Let me know if this is a benign OOM issue, so I can try getting a better bisection range.
Setting s-s to be safe. Jan, I don't know if this is a JIT or a wasm issue, do you mind taking a look?
Updated•1 year ago
|
Comment 1•1 year ago
|
||
Yury, this is likely Wasm SIMD related, likely a failure to propagate OOM. I looked at this a little bit and maybe EmitLoadExtendSimd128
needs to check the return value of loadExtendSimd128
?
Assignee | ||
Comment 2•1 year ago
|
||
(In reply to Jan de Mooij [:jandem] from comment #1)
Yury, this is likely Wasm SIMD related, likely a failure to propagate OOM. I looked at this a little bit and maybe
EmitLoadExtendSimd128
needs to check the return value ofloadExtendSimd128
?
Just a thought: the EmitLoadExtendSimd128 does the same thing as in most of methods in this file, e.g. EmitI32Const. If it is the issue with checking the return value, the same logic has to be applied to other 45 instances of f.iter().setResult(f.xxx
.
Comment 3•1 year ago
|
||
(In reply to Yury Delendik (:yury) from comment #2)
Just a thought: the EmitLoadExtendSimd128 does the same thing as in most of methods in this file, e.g. EmitI32Const. If it is the issue with checking the return value, the same logic has to be applied to other 45 instances of
f.iter().setResult(f.xxx
.
I think the difference is that MWasmLoad::New
is fallible but MConstant::New
isn't. Another option is to make some of these (smaller) fallible allocations infallible similar to the MIR instruction allocation itself.
Updated•1 year ago
|
Comment 4•1 year ago
|
||
Is this a security issue? How much of one if so?
Assignee | ||
Comment 5•1 year ago
•
|
||
(In reply to Andrew McCreight [:mccr8] from comment #4)
Is this a security issue? How much of one if so?
The issue only present when out-of-memory triggered when JIT compiler works. The worst case is the process will crash with MOZ_ASSERT() or during access of (near-)zero address.
Updated•1 year ago
|
Assignee | ||
Comment 6•1 year ago
|
||
Updated•1 year ago
|
Comment 8•1 year ago
|
||
bugherder |
Comment 9•1 year ago
|
||
The patch landed in nightly and beta is affected.
:yury, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox124
towontfix
.
For more information, please visit BugBot documentation.
Assignee | ||
Comment 10•1 year ago
|
||
Not really important due to OOM, but can be uplifted if there will be an evidence widespread crashes.
Updated•1 year ago
|
![]() |
Reporter | |
Updated•1 year ago
|
Updated•1 year ago
|
Description
•