Closed Bug 1385717 Opened 8 years ago Closed 8 years ago

Rejection of valid wasm binary

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: azakai, Unassigned)

Details

Attachments

(2 files)

7.81 KB, application/octet-stream
Details
13.78 KB, application/x-javascript
Details
Attached file b.wasm
The attached binary seems to be valid (is accepted by v8, wabt, binaryen) but is rejected by sm with b.js:22:41 CompileError: at offset 4169: unused values not explicitly dropped by end of block Using wabt's wasmdump, the relevant part seems to be the end of a (valueless) if, 001043: 0c 02 | br 0x2 001045: 45 | i32.eqz 001046: 00 | unreachable 001047: 0d 01 | br_if 0x1 001049: 0b | end I'm not totally sure here, but looks like the br_if is to a block with a value, so it is popping the value and then the condition. Then it re-pushes the value, which is the unreachable. That should make the stack polymorphic, so it's valid code?
Attached file b.js
JS file to run the wasm, using js b.js b.wasm (i.e. the binary as a second arg). (The JS runs a bunch of executions as well, this is fuzzer output, which are not really needed here since the issue is in validation.)
Thanks for digging into this! I think SM is actually right here and the spec interpreter confirms with validation error: b.wasm:0xfd6: invalid module: type mismatch: operator requires [] but stack has [i32] The signature of 'unreachable' is [t*]->[t*] which means that it can take and produce anything required for validation to succeed. However, the following br_if explicitly leaves a monomorphic i32 on the top of the stack, leaving the stack [t* i32]. So even if we make t* = [], there is still that i32 at the top of the stack so validation must fail. So probably it'd be good to file a bug on v8 and wabt. Tentatively closing, but feel free to reopen if I've been to hasty.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: