emscripten-core / emscripten-core/emscripten

Module instantiation fails on the worker thread when compiled with both `-sWASM=2` and `-pthread`.

Open
#19,147 7 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
27.6k
Forks
3.6k
Avg merge
1d 1h
Merged PRs (30d)
105

Description

**Version of emscripten/emsdk:**

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.31 (e88336121cfe6da4a96c88e46f314552f07dfed0)

**Failing command line in full:**

`emcc -sWASM=2 -pthread -sPTHREAD_POOL_SIZE=1 emptyfile.c `
(`PTHREAD_POOL_SIZE` is set in order to trigger thread spawn right away.)

Given that COOP and COEP headers are properly set, visiting a page that loads the output `.js` (``) causes the following error.

Firefox: `LinkError: import object field 'memory' is not a Memory`
Chrome: `LinkError: WebAssembly.Instance(): Import #24 module="env" function="memory" error: memory import must be a WebAssembly.Memory object`

When `new WebAssembly.Instance()` is called in `.worker.js`, `info.env.memory` is indeed not a `WebAssembly.Memory` instance, but a custom object. This traces back to `library_pthread.js`(https://github.com/emscripten-core/emscripten/pull/11505), whose comments indicate that there is a reason why `wasmMemory` is not passed directly. (Passing it directly seems to cause no problems for me.)

(Nevertheless,) I tried to create a new `Memory` instance on the worker side, but couldn't figure out the proper way.

By the way, the problem doesn't occur if `-sWASM=0`, even though the custom object is passed in this case too. (Is `memory` not used if the module is loaded from a `.wasm.js`?)

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.