WebAssembly.Memory cannot be cloned in this context

nagyimre

Hi,

I am playing around with Qt 5.13.1 (EMSDK 1.38.31) WASM. I successfully created an application during the summer, it was performant and so much fun. Some days ago when testing this application with FF Nighly and Chrome Canary, it did not work anymore, I only got the "WebAssembly.Memory cannot be cloned in this context" error. As far as I know, the FF and Chrome developers modified some settings to make the browsers more secure, but it means - at least for us now - that Qt base applications are not runnable anymore with the toolchain we used to create them.

So, questions:

did you experience anything related to this issue?
if this was fixed, whixh Qt and EMSDK version was used for it?

Thanks,
I.

lorn.potter

I just got this same error today using firefox nightly. Did not seem to happen with firefox version 69.0.1

I will look into this.

nagyimre

@lorn-potter It does happen with https://www.qt.io/web-assembly-example-mandelbrot

I have talked with FF developers and they said that they introduced some internal strict limits of what object could be cloned. They also stated that they are not talking with Qt devs. I have opened a bug report on Mozilla side: https://bugzilla.mozilla.org/show_bug.cgi?id=1586217

I do assume, that this issue is somehow related to that .mem file cannot be copied into the memory (failing some attributes, clearance, IDK), since the symptomes looks like the situation when you are not putting the .mem file next to the .wasm.

We experience this issue since around 8-10 days.

tham

@lorn-potter Tried with FF 69.0.2, https://www.qt.io/web-assembly-example-mandelbrot

Error message :

CompileError: wasm validation error: at offset 5711: shared memory is disabled

nagyimre

@tham That's different. If you use a threaded version of a Qt application in FF or Chrome, you need to enable shared memory by default (even Qt docs are referring to it). This context clone issue is related to a current change in FF internals to make FF a bit more multiprocess friendly, but it turned out that it disabled all threaded WASM applications (Qt, Rust, etc frameworks) Mozilla elevated the issue to P1 and seesm they would fix in the near future.

lars.t.hansen

We're looking into it. This is likely a consequence of changes we're making to reenable shared memory in JS and Wasm in Firefox. These changes will require sites that want to use shared memory to opt into a sandbox mechanism (there's an evolving cross-browser spec for this) so as to avoid Spectre-type side channel attacks.

Specifically, to allow modules containing shared memory to be cloned with postMessage, the server needs to serve the content over HTTPS, and I had to add the following to my http server config file:

<Directory /var/www/sandbox/raytrace>
        Header set Cross-Origin-Opener-Policy same-origin
        Header set Cross-Origin-Embedder-Policy require-corp
</Directory>

(That's probably overly broad but it should be OK) and in Firefox you must enable two prefs in about:config:

javascript.options.shared_memory
dom.postMessage.sharedArrayBuffer.withCOOP_COEP

Very gory details about the changes to the HTTP spec here: https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k

nagyimre

Thanks. According to this: https://bugzilla.mozilla.org/show_bug.cgi?id=1586217 these changes are more on DevOps side (server maintenance) than actual coding. Anyhow, QT WASM documentation should be updated to define this issue.

I try to make the requested changes from the above link to see whether that solves the issue. I will report back with the results.

lorn.potter

@nagyimre said in WebAssembly.Memory cannot be cloned in this context:

@lorn-potter It does happen with https://www.qt.io/web-assembly-example-mandelbrot

I have talked with FF developers and they said that they introduced some internal strict limits of what object could be cloned. They also stated that they are not talking with Qt devs. I have opened a bug report on Mozilla side: https://bugzilla.mozilla.org/show_bug.cgi?id=1586217

Thank you!

lorn.potter

I guess this means not being able to use emrun, as I do not think it handles https

nagyimre

@lorn-potter In nutshell, if you did not read Mozilla bug: it requires HTTPS and 2 header modifications in the HTTP response header. (we are running our QT WASM application in FF Nightly again)

I think you are right and emrun is out of scope for this. If I have time I do make up a documentation (at least for apache) so you could include into 5.14 delivery.

lars.t.hansen

We're trying to implement a workaround for FF Nightly and DevEd to ease developer pain: https://bugzilla.mozilla.org/show_bug.cgi?id=1587394.

lars.t.hansen

In Firefox Nightly or Developer Edition only, it should now be possible to set the preference "dom.postMessage.sharedArrayBuffer.bypassCOOP_COEP.insecure.enabled" to "true" in about:config to allow development in simpler environments (ie the headers will not be required). Going forward, deployment to Beta and Release browsers will still require the headers and HTTPS. Do let us know if development remains difficult.

mahsda30

This post is deleted!

lorn.potter

@nagyimre You don't know what I've read, so don't assume you do. I know all about the bug you posted. I was probably the first Qt developer to experience it. The Qt WebAssembly wiki even mentions this bug, which we put there so developers would see it. https://wiki.qt.io/Qt_for_WebAssembly

I just assumed you were testing with emrun.

mahsda30

This post is deleted!