1623385 - Trying to console.log a `SharedArrayBuffer` asserts

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P1)

Description

[Paul Adenot (:padenot)]

Attachment: aw-shared-memory.html

MOZ_ASSERT(!mCallData); doesn't hold in the attached test case. That crashes the tab in debug.

In non-debug, it seem to work, but the console.log statements that have a SharedArrayBuffer as argument don't appear in the console. The SharedArrayBuffer seem however to be valid in the AudioWorkletGlobalScope side, accessing one of its properties like byteLength returns the correct result.

I tried a normal SharedArrayBuffer and a shared WASM heap.

Comment 1

[Paul Adenot (:padenot)]

This test case is a reduced version of what VLC.js does. They uses a shared WASM heap for its operation: the VLC codebase, compiled to WASM, writes audio in a ring buffer, that an AudioWorkletProcessor dequeues for playback. There is no audio currently in Firefox (there is audio in Chrome, but no video, for some reason) so I was debugging it but I found this.

Comment 2

[Paul Adenot (:padenot)]

Baku, Karl, it's a bit unclear to me what happens here, it seems like the object works, but we can't log it. But also there is no audio in Firefox, so I'm trying to debug this without console.log.

Comment 3

[Karl Tomlinson (:karlt)]

Thank you for the testcase, Paul.
I'm modifying this code to address bug 1492011, and so will ensure this assertion is fixed too.

console.log() does not support passing all kinds of objects between threads; some are converted to strings, but i don't see that happening here.
I'll leave ni?baku in case he knows off-hand what should be expected for SAB.

The testcase can be run on Nightly with these prefs.
dom.postMessage.sharedArrayBuffer.bypassCOOP_COEP.insecure.enabled
dom.audioworklet.enabled
dom.worklet.enabled

Comment 4

[Karl Tomlinson (:karlt)]

In case it is helpful for debugging VLC, console.log(e.data.data + "") prints [object SharedArrayBuffer], which is similar to what dump() does.

Comment 5

[Andrea Marchesini [:baku]]

The bug is in the Console and in StructuredCloneData: we are unable to send a sharedArrayBuffer via Console API because we use a generic CloneDataPolicy. There is nothing related to worklet and I can reproduce this bug using a worker too.
Karl, if you want I can take this bug.

Comment 6

[Karl Tomlinson (:karlt)]

Thank you, Andrea. If this is about the CloneDataPolicy, then yes please take it.

Comment 7

[Paul Adenot (:padenot)]

(In reply to Karl Tomlinson (:karlt) from comment #4)

In case it is helpful for debugging VLC, console.log(e.data.data + "") prints [object SharedArrayBuffer], which is similar to what dump() does.

VLC now works, it was a race in their setup code between an onmessage handler (that is used to receive part of the WASM heap to be able to setup a ring buffer between the VLC code and the AudioWorklet) and the first process, which we solved by simply returning true from process if the SharedArrayBuffer hasn't been received yet.

Their code can now play video with sound, AV sync is good.

Comment 8

[Andrea Marchesini [:baku]]

Attachment: Bug 1623385 - Console API must support the logging of SharedArrayBuffers, r?smaug

Comment 9

[Andrea Marchesini [:baku]]

Landing the patch because this crash happens in debug build only and it's an internal MOZ_ASSERT().

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/c9c7f800aae6
Console API must support the logging of SharedArrayBuffers, r=smaug

Comment 11

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/c9c7f800aae6