Unknown name subsection when using wasm-opt on custom .wasm

[alstrup]

I have a .wasm file, which produces the error above when trying to run "wasm-opt euler7.wasm". When I try to run -O2 on it, it crashes with the latest release.
euler7.zip

[kripken]

I think that warning may happen if the wasm uses name section subsections, like the locals subsection. We still need to add support for that. Btw, what compiler created that wasm, do you know?

Testing on v68, I don't see a crash with -O2 (it successfully shrinks it by around 17%). Do you have a stack trace? Or running valgrind may find something (I don't see anything here).

[alstrup]

It is our own compiler for a functional language called flow - not related to the flow from Facebook. I ran the tool in the Windows Subsystem for Linux, so the crash might be related to that. When I run with gdb, I get this stacktrace, which is probably not much help:

Starting program: /mnt/c/work/binaryen-version_68/wasm-opt -O2 euler7.wasm
unknown name subsection at 25318
[New LWP 378]
[New LWP 379]
[New LWP 380]
[New LWP 381]

Thread 5 "wasm-opt" received signal SIGABRT, Aborted.
[Switching to LWP 381]
0x0000000000766428 in ?? ()
(gdb) bt
#0 0x0000000000766428 in ?? ()
#1 0x000000000076646a in ?? ()
#2 0x0000000000000000 in ?? ()

If it helps, I attach the .wat behind the .wasm file.
euler7.zip

[kripken]

Interesting. Would a debug build in WSL show a better stack trace? Or does it have limitations? If you can run valgrind in a debug build in WSL that might be especially interesting.

[kripken]

Also may be interesting to see if the test suite passes on WSL (python check.py).

[alstrup]

It runs and runs, and then fails at this point:

executing: bin/wasm-opt split.wast -O
(no output file specified, not emitting output)
(binary format check)
bin/wasm-as split.wast -o a.wasm -g
bin/wasm-dis a.wasm -o ab.wast
bin/wasm-opt ab.wast
(no output file specified, not emitting output)
executing: bin/wasm-shell ab.wast
.. spec/unwind.wast
executing: /mnt/c/Program Files/nodejs/node.exe -e process.stdout.write(typeof WebAssembly)
net.js:145
this._handle.open(options.fd);
^

Error: EINVAL: invalid argument, uv_pipe_open
at Error (native)
at new Socket (net.js:145:18)
at createWritableStdioStream (internal/process/stdio.js:156:16)
at process.getStdout [as stdout] (internal/process/stdio.js:10:14)
at [eval]:1:8
at ContextifyScript.Script.runInThisContext (vm.js:25:33)
at Object.exports.runInThisContext (vm.js:77:17)
at Object. ([eval]-wrapper:6:22)
at Module._compile (module.js:570:32)
at bootstrap_node.js:357:29
Traceback (most recent call last):
File "check.py", line 635, in
sys.exit(main())
File "check.py", line 611, in main
run_binaryen_js_tests()
File "check.py", line 432, in run_binaryen_js_tests
node_has_wasm = NODEJS and node_has_webassembly(NODEJS)
File "/mnt/c/work/binaryen/scripts/test/support.py", line 173, in node_has_webassembly
return run_command(cmd) == 'object'
File "/mnt/c/work/binaryen/scripts/test/support.py", line 160, in run_command
raise Exception(('run_command failed (%s)' % code, out + str(err or '')))
Exception: ('run_command failed (1)', '')

[kripken]

Interesting, thanks, I guess it's not too surprising to see node differences like that between platforms (emscripten's NODERAWFS mode has several open issues on that). I guess our test suite is not fully portable because of that.

[alstrup]

The tool worked when I ran it on the original .wat based on master, so I guess we can close this.