Closed Bug 1254188 Opened 6 years ago Closed 6 years ago

[wasm] Assertion failure: !producer->isDiscarded(), at js/src/jit/IonAnalysis.cpp:2253

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla48
Tracking Status
firefox47 --- wontfix
firefox48 --- fixed

People

(Reporter: decoder, Assigned: luke)

Details

(Keywords: assertion, regression, testcase)

Attachments

(2 files)

The attached binary WebAssembly testcase crashes on mozilla-inbound revision 2f9b726495d1+ (build with --enable-gczeal --enable-optimize --enable-debug --enable-address-sanitizer --without-intl-api --enable-posix-nspr-emulation --disable-jemalloc --disable-tests --enable-debug, run with ). To reproduce, you can run the following code in the JS shell:

var data = os.file.readFile(file, 'binary');
wasmEval(data.buffer);


Backtrace:

==32451==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000cecbd7 bp 0x7fff6b3e62b0 sp 0x7fff6b3e62a0 T0)
    #0 0xcecbd6 in CheckOperand(js::jit::MNode const*, js::jit::MUse const*, int*) js/src/jit/IonAnalysis.cpp:2251:5
    #1 0xcbbf64 in js::jit::AssertBasicGraphCoherency(js::jit::MIRGraph&) js/src/jit/IonAnalysis.cpp:2380:13
    #2 0xcb28a2 in js::jit::OptimizeMIR(js::jit::MIRGenerator*) js/src/jit/Ion.cpp:1516:5
    #3 0x8806f2 in js::wasm::IonCompileFunction(js::wasm::IonCompileTask*) js/src/asmjs/WasmIonCompile.cpp:3100:14
    #4 0x87f638 in js::wasm::ModuleGenerator::finishFuncDef(unsigned int, unsigned int, js::wasm::FunctionGenerator*) js/src/asmjs/WasmGenerator.cpp:815:14
    #5 0x85b158 in DecodeFunctionBody(JSContext*, js::wasm::Decoder&, js::wasm::ModuleGenerator&, unsigned int) js/src/asmjs/Wasm.cpp:1287:12
    #6 0x85b158 in DecodeFunctionBodies(JSContext*, js::wasm::Decoder&, js::wasm::ModuleGenerator&) js/src/asmjs/Wasm.cpp:1308
    #7 0x85b158 in DecodeModule(JSContext*, mozilla::UniquePtr<char [], JS::FreePolicy>, unsigned char const*, unsigned int, mozilla::Vector<ImportName, 0ul, 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:1407
    #8 0x8528c6 in js::wasm::Eval(JSContext*, JS::Handle<js::TypedArrayObject*>, JS::Handle<JSObject*>, JS::MutableHandle<JSObject*>) js/src/asmjs/Wasm.cpp:1539:10
    #9 0x55df3c in WasmLoop(JSContext*, unsigned int, JS::Value*) js/src/shell/js.cpp:5073:14
    #10 0x1d20417 in js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) js/src/jscntxtinlines.h:235:15
[...]
    #22 0x48a573 in _start (/home/ubuntu/build/build/js+0x48a573)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV js/src/jit/IonAnalysis.cpp:2251 CheckOperand(js::jit::MNode const*, js::jit::MUse const*, int*)
==32451==ABORTING
Attached file Testcase
Fantastic test case!  Phi recycling.  This case is only possible via wasm and loops-returning-values which is why it's not caught by asm.js.
Assignee: nobody → luke
Status: NEW → ASSIGNED
Attachment #8728239 - Flags: review?(bbouvier)
Comment on attachment 8728239 [details] [diff] [review]
fix-dead-phi-loop-result

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

Nice, thanks for fixing it! This assertion was one of my nemesis, when implementing control flow opcodes...

::: js/src/jit-test/tests/wasm/random-control-flow.js
@@ +1,5 @@
> +load(libdir + "wasm.js");
> +
> +assertEq(wasmEvalText(`(module
> +   (func (result i32) (param i32)
> +     (loop (if (i32.const 0) (br 0)) (get_local 0)))

So br can be put in the loop condition without breaking the type system? If so, I've got a few test cases to re-enable in basic-control-flow.

Also, how do we decide what tests go to basic-* rather than to random-*? :-)
Attachment #8728239 - Flags: review?(bbouvier) → review+
(In reply to Benjamin Bouvier [:bbouvier] from comment #3)
> So br can be put in the loop condition without breaking the type system? If
> so, I've got a few test cases to re-enable in basic-control-flow.

Yes, a (br) has the Any type (if you think about it bottom-up) since it doesn't return to its parent but, rather, to the enclosing (block) or (loop).

> Also, how do we decide what tests go to basic-* rather than to random-*? :-)

My thought with random-* is that it's a nicer group together bug-related testcases than bugXYZ.js.
https://hg.mozilla.org/mozilla-central/rev/8a5afc96fd05
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
WASM disabled by default. Luke says no uplifts. WONTFIX 47.
You need to log in before you can comment on or make changes to this bug.