1821582 - `worker.postMessage` with a WebAssembly.Memory followed by 2 typed arrays doesn't work.

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, defect, P2)

Description

[DDR]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/109.0

Steps to reproduce:

I created a new WebAssembly.Memory(…). I also created an object with two Int32Arrays backed by the memory's buffer. Then I posted them to a worker and got different results depending on the order of the memory and the object.

I have uploaded a minimum reproduction to https://github.com/DDR0/Stardust/tree/memory-issue-2-reproduction. main.mjs sends the messages as detailed above, and sim.mjs echos the messages received to the console. I have included example_server.py to serve the files cross-origin-isolated, so shared memory gets enabled.

Actual results:

Console:

🛈 Worker Thread: [object Object],[object WebAssembly.Memory]. sim.mjs:1:47
⚠ [object MessageEvent] sim.mjs:2:45
🛈 Worker Thread: [object Object],[object WebAssembly.Memory]. sim.mjs:1:47
⚠ [object MessageEvent]  sim.mjs:2:45

Expected results:

Console:

🛈 Worker Thread: [object Object],[object WebAssembly.Memory]. sim.mjs:1:47
🛈 Worker Thread: [object WebAssembly.Memory],[object Object]. sim.mjs:1:47
🛈 Worker Thread: [object Object],[object WebAssembly.Memory]. sim.mjs:1:47
🛈 Worker Thread: [object WebAssembly.Memory],[object Object]. sim.mjs:1:47

Note: The above shows up if I back the memory with a normal SharedArrayBuffer(10) or only have one TypedArray in the object. The typed arrays don't have to be in the object.

Note: While Chromium does transfer [memory, object], it transfers [object, memory] as null, firing the worker's message event in both cases. This issue does not reproduce in Firefox, and only needs one typed array instead of two. I have filed it with them at https://bugs.chromium.org/p/chromium/issues/detail?id=1421524.

Thank you!

Comment 1

[Rares Doghi, Desktop QA]

Im not sure if this is the correct component for this issue, hopefully one of our devs can take a look and move it to a more suitable one.

Comment 2

[DDR]

The sister Chromium issue, mentioned above, has been fixed now.

Comment 3

[Ryan Hunt [:rhunt]]

Ben, could you take a look?

Comment 5

[Yury Delendik (:yury)]

Attachment: Bug 1821582 - Preserve SharedArrayBuffer identity during WebAssembly.Memory cloning. r?sfink

Use startWrite for the SharedArrayBuffer in writeSharedWasmMemory to ensure
it gets registered in the memory map. This allows subsequent references from
typed arrays to use back-references instead of creating duplicate buffers.

Add the SharedArrayBuffer to allObjs in readSharedArrayBuffer so
back-references can be resolved during deserialization.

This preserves buffer identity across structured cloning.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/41839dfe700a
https://hg.mozilla.org/integration/autoland/rev/7eb3b11c1e7d
Preserve SharedArrayBuffer identity during WebAssembly.Memory cloning. r=sfink

Comment 7

[amarc]

https://hg.mozilla.org/mozilla-central/rev/7eb3b11c1e7d