Type mismatch on validation

[jmid]

Describe the bug

Consider the following Wasm module:

(module
  (type $0 (func (param) (result i32)))
  (func $0
    (type 0)
    (i32.const 0)
    (i32.const 0)
    (i32.const 0)
    (i32.const 0)
    (unreachable)
    (br_if 0)
    (select)
  )
)

When validating the module I get a wasmer validation error, even though the module should validate.

I don't have the rust-compiler installed (not needed to reproduce), and I'm on Mac OSX Mojave:

$ echo "`wasmer -V` | `uname -m`"
wasmer 1.0.0-alpha4 | x86_64

Steps to reproduce

$ spec/interpreter/wasm -d type-mismatch-reduced.wat -o type-mismatch-reduced.wasm
$ wasmer validate type-mismatch-reduced.wasm 
error: failed to validate `type-mismatch-reduced.wasm`
╰─> 1: Validation error: type mismatch: not enough operands (at offset 35)

Expected behavior

I was expecting the module to validate without an error.
This is the case for the reference validator (part of the above conversion) and for wasm-validate from wabt:

$ wabt/bin/wasm-validate type-mismatch-reduced.wasm 
$ echo $?
0 

This is also the case for the validator implementations inside V8, Chakra, SpiderMonkey, and JavaScriptCore installed via jsvu:

$ v8 type-mismatch-reduced.js
true
$ ch type-mismatch-reduced.js
true
$ sm type-mismatch-reduced.js
true
$ jsc type-mismatch-reduced.js
true

when validating the corresponding, self-contained module:

const buffer = new Uint8Array([ 0,97,115,109,1,0,0,0,1,133,128,128,128,0,1,96,0,1,127,3,130,128,128,128,0,1,0,10,148,128,128,128,0,1,142,128,128,128,0,0,65,0,65,0,65,0,65,0,0,13,0,27,11 ]);
print(WebAssembly.validate(buffer));

Actual behavior

The validation fails.

[syrusakbary]

@jmid it seems you are using Wasmer from Python. Which version of Wasmer are you using?

Note: we just released a few weeks ago the 1.0 alpha version

[jmid]

@syrusakbary This is wasmer 1.0.0-alpha4 (also included in the original bug report)

Note: I'm not using Wasmer from Python. I have a vanilla Wasm-module which fails to validate,
while it validates with the reference interpreter/validator, with wabt, and with V8, Chakra, SpiderMonkey, and JavaScriptCore when expressed as a self-contained JavaScript program.

[nlewycky]

It looks like this is a bug in the version of wasmparser we're using and already fixed in the latest release of wasmparser. Wasmparser has changed enough that updating will require some effort.