Is there some fundamental bug in 32 bit Chrome with regard to WebAssembly ?

[Gaurav Dewan]

Is there some known bug in wasm pages opened in 32 bit chrome ?

My Wasm based application is working fine in 32 bit firefox and all 64 bit browsers.

But on 32 bit Chrome, I get black patches all over the canvas(cpu rendering only)

[Jukka Jylänki]

Haven't heard about any issues here. The test case I have been working on the most is http://mzl.la/webassemblydemo , which seems to work well on Chrome.

Try to reduce down to a minimal test case and report it to Chrome bug tracker?

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gaurav Dewan]

I was trying the demo on 32 bit chrome - What does this demo do? It just keeps showing downloading spinner on chrome 32 bit

http://mzl.la/webassemblydemo 

It built shaders(23 seconds) compile webassembly(28 mb) downloading(39Mb/39Mb - 100% and spinner is moving) 

Failed to store file wasmModule to IndexedDB, error: DataCloneError: Failed to execute 'put' on 'IDBObjectStore': An object could not be cloned.

This is expected on chrome as chrome does not have structured cloning support for WASM.

[Floh]

I haven't noticed differences between Chrome 32-bit and 64-bit on Windows 7 in my demos so far:

https://floooh.github.io/oryol/

https://floooh.github.io/oryol-samples/

https://floooh.github.io/virtualkc/

(all of these default to asm.js, select the WASM version by clicking on the 'wasm' links below the screenshots on the demo pages, or in the emulator by clicking the hamburger item and then "wasm version").

The 32-bit Chrome version I'm testing on is "Version 57.0.2987.10", and for 64-bit "Version 59.0.30550.canary (64-bit)"

Cheers,

-Floh.

[bobajeff]

Hey floh, I was going over your wasm demos and am happy to report that they work superb on Chrome for Android (have Nexus 6) except a few ones that use DDS Textures. (The same issues as their asm.js versions.)

I get some messages like:

'unsupported texture format for resource ...'

Thanks for providing us simple tests cases I've learned quite a bit them.

[Gaurav Dewan]

I am able to pinpoint the point of failure in my program - at one place I am calling a function (passing it 6 floating points and int as last argument). Inside that function, second last argument comes out to be garbage (unexpected) while it is okay from where I am calling it (it all happens in header file in precompiled header). This anomaly happens only in 32 bit chrome with webassembly version - works fine in 64 bit browser or 32 bit FF. Asm.js works fine as well

In C, I know such errors are caused by calling convention or prototype  mismatch - the same can be confirmed by assembly debugging. It does not appear to be that case here.

In a small testcase, I am unable to repro this issue.
How can I debug further to create a small test case for repro ? Is there a webassembly tool available to ease this job? seeing wast of this function or debugging ?

[Alon Zakai]

There is some debugger support in browsers, using the normal devtool debuggers but I'm not sure how stable/useful it is. Worth trying (I would use latest dev versions, so canary for chrome or nightly for firefox).

Otherwise, this sounds like a browser bug in chrome, so if you can post a bug with a public build of your full project, even if it's not a reduced testcase, that is a good idea. If you can put some printfs near the problem area, that can help the browser devs even more. Build should optimally have -g or --profiling, and -s DETERMINISTIC=1.

--

[Gaurav Dewan]

Interestingly, if I debug wasm using devtool (chrome 32 bit) and put a breakpoint at wasm function just before the call site and single step through wasm code, the bug does not happen. But if i put a breakpoint inside the called function - i get garbage value as second last parameter(as seen in dev tools) of the function (last int argument is fine)

I have logged the following bug:

https://bugs.chromium.org/p/chromium/issues/detail?id=718858

I tried to play at wasm playground: http://mbebenita.github.io/WasmExplorer/ and also used wasm-dis / -g4 option on various combination in C++ file but I could not figure out how to force emscripten toolchain to generate similar WAST code as in large program. So I have logged the bug by illustrating the wast instructions which lead to bug. Hopefully that would lead to repro; unless the bug is triggered by complex optimizations happening inside chrome on large codebase.