Massive icon indicating copy to clipboard operation
Massive copied to clipboard

Wasm.instantiateModule(): Result = expected version 0b 00 00 00, found 0a 00 00 00 @+4

Open frxstrem opened this issue 8 years ago • 12 comments

When I'm running the benchmarks, it stops at the second benchmark (box2d-wasm-throughput) with this exception in the console:

benchmark-worker.js:64
Uncaught Error: Uncaught Wasm.instantiateModule(): Result = expected version 0b 00 00 00,
found 0a 00 00 00 @+4
    at onmessage (http://kripken.github.io/Massive/beta/box2d/benchmark-worker.js:64:3)
    onmessage @ benchmark-worker.js:64

Running in Chrome 54 beta.

frxstrem avatar Sep 12 '16 03:09 frxstrem

The wasm benchmarks here use 0xa wasm, while browsers currently use 0xb. Emscripten and Binaryen are now somewhere between 0xb and 0xc, so we can probably update these tests to 0xc when that stabilizes (probably a few weeks). Overall, wasm is in a lot of flux now so it's hard to get everything in sync all the time.

kripken avatar Sep 12 '16 16:09 kripken

I have a demo that is now broken under Canary, I didn't changed anything, is it because my browser downloaded an update? And how to solve it, just update emsdk once it's using 0xc?

leefsmp avatar Sep 29 '16 21:09 leefsmp

Yes, canary has been updating the wasm version over the last week. Once emscripten has 0xc support, updating the emsdk should fix things.

kripken avatar Sep 29 '16 21:09 kripken

Cool, do you have an estimate - roughly - about when emscripten is upgraded to 0xc? Thanks

leefsmp avatar Sep 29 '16 22:09 leefsmp

There should be just some final binary fixes, hopefully a matter of days.

kripken avatar Sep 29 '16 23:09 kripken

Can you help with the following error?

./emsdk update ./emsdk install sdk-incoming-64bit ...

CMake Error: The current CMakeCache.txt directory /Users/leefsmp/emsdk/clang/fastcomp/build_incoming_64/CMakeCache.txt is different than the directory /Users/leefsmp/emscripten/clang/fastcomp/build_incoming_64 where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt CMake Error: The source "/Users/leefsmp/emsdk/clang/fastcomp/src/CMakeLists.txt" does not match the source "/Users/leefsmp/emscripten/clang/fastcomp/src/CMakeLists.txt" used to generate cache. Re-run cmake with a different source directory. CMake invocation failed due to exception! Working directory: /Users/leefsmp/emsdk/clang/fastcomp/build_incoming_64 Command '['cmake', '-G', 'Unix Makefiles', '-DCMAKE_BUILD_TYPE=RelWithDebInfo', '-DPYTHON_EXECUTABLE=/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python', '-DLLVM_TARGETS_TO_BUILD=X86;JSBackend', '-DLLVM_INCLUDE_EXAMPLES=OFF', '-DCLANG_INCLUDE_EXAMPLES=OFF', '-DLLVM_INCLUDE_TESTS=OFF', '-DCLANG_INCLUDE_TESTS=OFF', '/Users/leefsmp/emsdk/clang/fastcomp/src']' returned non-zero exit status 1 Installation failed!

leefsmp avatar Oct 11 '16 08:10 leefsmp

Ok I've wipeout my old SDK, updated CMake, downloaded and installed a fresh version ... now getting this when loading my wasm in canary:

failed to compile wasm module: Error: Wasm.instantiateModule(): Wasm decoding failedResult = section was longer than expected size (186 bytes expected, 187 decoded) @+201

leefsmp avatar Oct 11 '16 11:10 leefsmp

Sadly we are not yet compatible. There are a bunch of known issues, and I'm actually not sure how many are masked by them that we don't see yet. So could be another week or two.

kripken avatar Oct 11 '16 17:10 kripken

Is there a browser where i can run wasm right now? my code doesnt load in firefox nightly either and I've got a meetup tomorrow where I wanted to demo some stuff ... can i get a version of canary compat with my sdk? thx for quick feedback

leefsmp avatar Oct 11 '16 18:10 leefsmp

The main wasm demo (angry bots) should work in firefox nightly and chrome canary. But toolchains and browsers aren't in sync enough to run code you compile yourself. You could in theory use an old canary or nightly (e.g. old firefoxes are here) that supports 0xb (probably a month or two ago is ok), plus binaryen on it's 0xb tag, should work.

kripken avatar Oct 11 '16 18:10 kripken

The wasm benchmarks here use 0xa wasm, while browsers currently use 0xb.

Any plans/updates about updating these to 0xc/0xd in wasm branch? Would be nice to have a cross browser comparison for these wasm benchmarks. Also, I noticed that the Embenchen repo has 0xd wasm files for these benchmarks. I built wasm using binaryen from the asm.js files provided in this repo, to get the latest version. However, the JS file (which switch between wasm/asmjs) has some issues, as it hasn't been updated recently with newer constructs, so I couldn't run it. I'm guessing building with emscripten + binaryen from C++ source would solve all this. Any insights?

rahulchaphalkar avatar Nov 30 '16 00:11 rahulchaphalkar

I don't plan to update massive any time soon, since the startup etc. tests need to be rethought - because wasm startup works differently (explicit caching, etc.) - and I doubt I'll have time. But if you or someone else wants to do it that's great of course.

So until we figure out startup, what is left here is throughput, and for that, as you said embenchen has 0xd binaries which test it, and it covers much of the same ground, plus some more. Not a pretty benchmark but when people ask me for something for internal testing I point them to it.

Yeah, just building the asm.js won't work out the box. Worse, it would not use all wasm opts, so it's not a good measurement. Need to build from scratch from source (driver.js has instructions), as you said.

kripken avatar Nov 30 '16 00:11 kripken