1300307 - WebAssembly file not parsed correcly

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[konsoletyper]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.89 Safari/537.36

Steps to reproduce:

Produced wasm file with my compiler (http://teavm.org/live-examples/wasm/classes.wasm), created an html page (http://teavm.org/live-examples/wasm/index.html) that loads this wasm file and opened in Firefox. Also, I tried to generate wast file and transform it to wasm via ml-proto, it isn't opened a


Actual results:

Firefox reported in developer's console:
TypeError: wasm error: compile error at offset 703: bad type


Expected results:

This file should have been loaded, since reference implementation of WebAssembly (aka ml-proto) does not report any errors regarding this file. Or at least Firefox should provide some way to debug the problem (view parse log, provide more clear error message).

Comment 1

[Tooru Fujisawa [:arai]]

There is difference about "function bodies" encoding between ml-proto and the design documentation.

https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#function-bodies
>  | Field | Type |Description |
>  | ----- | ----- | ----- |
>  | body_size | `varuint32` | size of function body to follow, in bytes |
>  | local_count | `varuint32` | number of local entries |
>  | locals | `local_entry*` | local variables |
>  | ast    | `byte*` | post-order encoded AST |

the design documentation says `body_size` should be the first field of function bodies.
Firefox also expects `body_size` as the first field.


https://github.com/WebAssembly/spec/blob/master/ml-proto/spec/decode.ml#L525
> let code s =
>   let locals = List.flatten (vec local s) in
>   let size = vu s in
>   let body = expr_block (substream s (pos s + size)) in
>   {locals; body; ftype = Source.((-1) @@ Source.no_region)}

ml-proto expects `local_count` as the first field.

So if the binary can be parsed with ml-proto, it means Firefox will fail to parse it.


Here's the content of function bodies of the binary:

  0x00
  0x0a
  0x01
  0x14
  0x00
  0x16
  0x01
  0xa7
  0x01
  0x09
  0x00
  0x0f

ml-proto parses it as:

  local_count = 0x00
  size = 0x0a           // maybe body_size ?
  ast =
    0x01                // block
    0x14 0x00           // get_local 0
    0x16 0x01 0xa7 0x01 // call 1, 167
    0x09 0x00           // return 0
    0x0f                // end

Firefox parses it as:

  body_size = 0x00
  local_cont = 0x0a
  locals =
    count = 0x01
    type = 0x14
    ...

and it throws "bad type" for 0x14.

Comment 2

[konsoletyper]

What description is more authoritative? I thought, spec is. There are few places in design repo that are unclear, until you look into ml_proto implementation. Also, ml_proto is simple and easy to debug, that helps developers to debug binary output of their compilers.

Comment 3

[Luke Wagner [:luke]]

The binary format is currently in in transition from 0xb to 0xc so I guess you're sampling ml-proto at an indeterminate state.  For that matter, the design/spec repos are also in flux, but we're keeping all the changes on the branch design/binary_0xc.  When everything is back in sync, ml-proto should match the browsers and we'll merge binary_0xc.  Sorry for the churn; this is intended to be the last significant change the binary format (with only a opcode renumbering planned as 0xd).

Comment 4

[konsoletyper]

Thank you for clarification. I found 3 differences between ml-proto and design. After applying corresponding changes to my wasm emitter, everything works fine in Firefox and surprisingly in Chrome, so I can conclude that design doc *is* de-facto a specification.