New issue
Advanced search Search tips

Issue 868404 link

Starred by 2 users
Status: Fixed
Owner: ----
Closed: Oct 25
Cc:
clemensh@chromium.org
adamk@chromium.org
titzer@chromium.org
dschuff@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Use of TextDecoder causes WebAssembly.instantiate to later fail

Reported by mdb...@gmail.com, Jul 27 
UserAgent: Mozilla/5.0 (X11; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce the problem:
1. Expand attached, which contains both source code and build products from emscripten 1.38.10
2. Open index.html

What is the expected behavior?
Should display "Success" in the console if the WebAssembly side module "module.so" loads correctly.

What went wrong?
The act of decoding a UTF-8 string on the emscripten WebAssembly heap using TextDecoder seems to cause a negative interaction such that the next call to WebAssembly.instantiate fails, rejecting the promise with an "undefined" error.

Did this work before? Yes 68.0.3440.75

Does this work in other browsers? Yes

Chrome version: 69.0.3493.3  Channel: dev
OS Version: Fedora 27
Flash Version: 

The component is more likely WebAssembly, but I chose Javascript as that wasn't an option.

Also see this gist for the source code: https://gist.github.com/mdboom/61bafc2b33e27d16f71ccbed1e9af0e5

Original bug report: https://github.com/iodide-project/pyodide/issues/93
textdecoder.tgz
935 KB Download

Comment 1 by alonza...@gmail.com, Jul 27 

I can confirm that behavior also in

Version 69.0.3486.0 (Official Build) dev (64-bit)
Version 69.0.3497.12 (Official Build) dev (64-bit)

on Ubuntu 16.04.

Btw, to see the testcase in action, the local web server must provide the right mime type (application/wasm) for the .wasm file, as the testcase uses streaming compilation (without that, it halts before printing "Success" or "Fail").

Comment 2 by dschuff@chromium.org, Jul 27

Cc: clemensh@chromium.org
Components: -Blink>JavaScript Blink>JavaScript>WebAssembly
Status: Available (was: Unconfirmed)
If this is a regression, could it be related to the baseline compiler?

(the baseline compiler can be enabled or disabled in chrome://flags so it should be easy to check that)

Comment 3 by dschuff@chromium.org, Jul 27

Labels: Arch-x86_64

Comment 4 by alonza...@gmail.com, Jul 27 

Doesn't look related to baseline - I disabled baseline, restarted, and still see the same behavior.

Comment 5 by clemensh@chromium.org, Oct 25

Status: Fixed (was: Available)
Can reproduce in M-69, but not in M-70. Considering fixed.
►

Sign in to add a comment