Closed
Bug 1260256
Opened 8 years ago
Closed 8 years ago
[wasm] Assertion failure: opBlock->dominates(*block) (Instruction is not dominated by its operands), at js/src/jit/IonAnalysis.cpp:2620
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox48 | --- | affected |
People
(Reporter: decoder, Unassigned)
References
Details
(Keywords: assertion, testcase)
Attachments
(1 file)
472 bytes,
application/octet-stream
|
Details |
The attached binary WebAssembly testcase crashes on mozilla-inbound revision 0fad49a543ea+ (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-address-sanitizer --disable-jemalloc --enable-optimize=-O2 --without-intl-api --enable-debug --target=i686-pc-linux-gnu). To reproduce, you can run the following code in the JS shell: var data = os.file.readFile(file, 'binary'); Wasm.instantiateModule(new Uint8Array(data.buffer)); Backtrace: ==26726==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000 (pc 0x08c3428f bp 0xff825528 sp 0xff8254d0 T0) ==26726==The signal is caused by a WRITE memory access. ==26726==Hint: address points to the zero page. #0 0x8c3428e in js::jit::AssertExtendedGraphCoherency(js::jit::MIRGraph&, bool) js/src/jit/IonAnalysis.cpp:2619:17 #1 0x8bc80aa in js::jit::OptimizeMIR(js::jit::MIRGenerator*) js/src/jit/Ion.cpp:1543:9 #2 0x835f607 in js::wasm::IonCompileFunction(js::wasm::IonCompileTask*) js/src/asmjs/WasmIonCompile.cpp:3122:14 #3 0x8328899 in js::wasm::ModuleGenerator::finishFuncDef(unsigned int, unsigned int, js::wasm::FunctionGenerator*) js/src/asmjs/WasmGenerator.cpp:815:14 #4 0x82bce97 in DecodeFunctionBody(JSContext*, js::wasm::Decoder&, js::wasm::ModuleGenerator&, unsigned int) js/src/asmjs/Wasm.cpp:1359:12 #5 0x82bce97 in DecodeFunctionBodies(JSContext*, js::wasm::Decoder&, js::wasm::ModuleGenerator&) js/src/asmjs/Wasm.cpp:1387 #6 0x82bce97 in DecodeModule(JSContext*, mozilla::UniquePtr<char [], JS::FreePolicy>, unsigned char const*, unsigned int, mozilla::Vector<ImportName, 0u, js::SystemAllocPolicy>*, mozilla::UniquePtr<js::wasm::ExportMap, JS::DeletePolicy<js::wasm::ExportMap> >*, JS::MutableHandle<js::ArrayBufferObject*>, JS::MutableHandle<js::WasmModuleObject*>) js/src/asmjs/Wasm.cpp:1486 #7 0x82b04f1 in js::wasm::Eval(JSContext*, JS::Handle<js::TypedArrayObject*>, JS::Handle<JSObject*>, JS::MutableHandle<JSObject*>) js/src/asmjs/Wasm.cpp:1643:10 #8 0x821f888 in WasmLoop(JSContext*, unsigned int, JS::Value*) js/src/shell/js.cpp:5212:14 [...] #21 0x80aaf98 in _start (/home/ubuntu/build/build/js+0x80aaf98) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV js/src/jit/IonAnalysis.cpp:2619:17 in js::jit::AssertExtendedGraphCoherency(js::jit::MIRGraph&, bool) ==26726==ABORTING
Reporter | ||
Comment 1•8 years ago
|
||
Comment 2•8 years ago
|
||
This is going to be fixed by the first patch in bug 1254142. I've reduced the test case to: (module (func (select (block $outer (block $inner (br_table $outer $inner (i32.const 1) ) ) (i32.const 2) ) (i32.const 3) (i32.const 4) ) ) ) What happens is that $outer gets assigned a value (i32.const 2), although it shouldn't be assigned one, because there's a jump from the br_table to outside $outer which doesn't yield a value. The function ensurePushInvariants introduced in the aforementioned patch fixes that by checking that all jumps to $outer yield a value, or none does; in the latter case, it returns a nullptr and the select isn't even emitted. So I think this will be solved by bug 1254142, without being a duplicate of the issue. Adding the test case in the other bug, will close this one as resolved fixed by 1254142 once it lands.
Depends on: 1254142
Flags: needinfo?(bbouvier)
Comment 3•8 years ago
|
||
Confirmed it's been fixed by the first patch landed in bug 1254142. I've verified locally.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(bbouvier)
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•