Open Bug 1613424 Opened 5 years ago Updated 1 year ago

Cannot log SharedArrayBuffer objects from a worker

Categories

(DevTools :: Console, defect, P2)

Product:
DevTools
Component:
Console
Type:
defect

Tracking

(Not tracked)

People

(Reporter: annevk, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

Run

new Worker(URL.createObjectURL(new Blob(['console.log(new SharedArrayBuffer())'], { type: "text/javascript" })))

in the console. If you replace SharedArrayBuffer with ArrayBuffer it works.

Note that currently we only enable this on early beta or earlier.

I think it would be ideal to fix this before we ship in 75 (without postMessage() support), so tentatively marking as blocking.

Hello Anne,

what do you get in the console? nothing?

I wonder if this is the same issue as in Bug 1215120.

Flags: needinfo?(annevk)

answering to my needinfo: there's nothing printed in the console

new Worker(URL.createObjectURL(new Blob([`
  console.log("inWorker");
  console.log(new SharedArrayBuffer())
  console.log("after sharedArrayBuffer");
`], { type: "text/javascript" })))

will show 2 logs: inWorker, after sharedArrayBugger .

Flags: needinfo?(annevk)

Yeah. This also happens if you do something like console.log("heya", sab). It will log nothing, not even "heya".

Gonna needinfo lth in case there's any special considerations for DevTools and SharedArrayBuffer that need to be taken into account.

Flags: needinfo?(lhansen)

(In reply to Anne (:annevk) from comment #0)

I think it would be ideal to fix this before we ship in 75 (without postMessage() support), so tentatively marking as blocking.

Without knowing scope or associated trade-offs, I agree with Anne's prioritization.

Last I checked, console structured-clones things over to send them to devtools... Is it possible that we're blocking doing that with a SAB and then not reporting the failure properly?

Priority: -- → P2
See Also: → 1215120

I'm out with the MozFlu and won't dig into this until Friday at the earliest, but comment 5 looks awfully plausible. Since the default cloning behavior for SAB and WebAssembly.Memory (you could try that too) is to block it, special permission must be requested, and of course it must be intraprocess.

Flags: needinfo?(lhansen)

Yeah, good call, we basically need a special serialization and deserialization path for DevTools for objects that have an AgentClusterId restriction.

The other thing we should look into is that DevTools also hooks into messageerror (or equivalent) as a fallback so that at least something comes out when serialization/deserialization fails.

Lars, if there are other things around shared memory and DevTools that might have been missed the initial time around it would be good to track those as well somewhere so we can ensure Firefox is great.

(In reply to Anne (:annevk) from comment #7)

Lars, if there are other things around shared memory and DevTools that might have been missed the initial time around it would be good to track those as well somewhere so we can ensure Firefox is great.

I don't know the devtools needs really. And I would never have guessed that the console needed to structured-clone values to be printed.

(I do know that we create separate instances of wasm machine code for the debugger so that breakpoints and other patches don't interfere with each other, so that should be fine even if modules are shared. Instances are per-worker and are arbitrarily mutable, so that should be fine too.)

I just found bug 1152856 which has a huge list of DevTools shared memory ideas from four years ago.

Blocks: 1152856

And I would never have guessed that the console needed to structured-clone values to be printed.

Well, the value starts out in the worker, in one thread (and one process), and needs to get shown in a different process (chrome process) and certainly on a different thread. What mechanism do we have for doing that with JS values other than structured cloning?

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #10)

And I would never have guessed that the console needed to structured-clone values to be printed.

Well, the value starts out in the worker, in one thread (and one process), and needs to get shown in a different process (chrome process) and certainly on a different thread. What mechanism do we have for doing that with JS values other than structured cloning?

I wouldn't want to speculate about that :-)

Anyway, if it's in a different process then vanilla SC should be a problem anyway, right? SABs aren't clonable cross-process ever.

Are normal ABs clobable cross-process? If so, then yes, we might need to do something special when people pass a SAB through the console API.

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #12)

Are normal ABs clo[n]able cross-process? If so, then yes, we might need to do something special when people pass a SAB through the console API.

At least in principle since ABs can be copied, and I would expect that with broadcasts they can indeed flow cross-process (I'm sketchy on the exact semantics but it was my understanding in the past that that could happen, and that this is why we have some really convoluted rules about what happens to SAB in that case.)

For messages in the console, copying a SAB should be OK too, but we have no provision for that right now.

ABs are, yes. I think for SABs we ideally have "serialization for console" rules that copy the underlying memory. And then ideally we make it apparent in the console that the memory of the logged object is a snapshot.

Surfacing deserialization failure however would be a good first step here, so we don't end up logging nothing at all. (This would also cover other potential failure scenarios, such as objects not being representable in the console, OOM, etc.)

nchevobbe, tell me if I'm wrong: The way console logs are taken from workers is changing. The new approach will not require StructuredClone, but instead, devtools actors in any debuggable worker. These actors will process the console log event directly from the worker thread. Note that this is already implemented for about:debugging. To be honest, I don't think we can switch to the actor-based console API before 75.

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #12)

Are normal ABs clobable cross-process? If so, then yes, we might need to do something special when people pass a SAB through the console API.

Yes, we support this. Basically we serialize the whole content of AB into the Structured Clone buffer. We can do something similar for SAB, probably.

Andrea is correct in comment 15. Thanks to the fission work we're doing, we'll connect the console directly to multiple targets (including workers).
I tried something quickly today but our APIs are not ready for that yet, and most certainly won't in 75 (and so far, we didn't plan to work on this for our current fission milestone, that would be for the next one).

Thanks Nicolas. So Fx 75 probably isn't needed as SharedArrayBuffer would still mostly not work (you can construct it, but not postMessage() it). It really depends on when COOP+COEP are ready and I haven't gotten clear estimates for those, but hope 76/77.

Talking with Luke this does not seem like a blocker as developers would likely not log the entire object anyway. It would be good to have fixed of course.

Blocks: 1563480
No longer blocks: 1606624
Severity: normal → S3

This issue is still present in Firefox 111.0.1.

console.log(new ArrayBuffer(10)) //works
console.log(new SharedArrayBuffer(10)) //doesn't work

(In reply to DDR from comment #19)

This issue is still present in Firefox 111.0.1.

console.log(new ArrayBuffer(10)) //works
console.log(new SharedArrayBuffer(10)) //doesn't work

This is probably blocked on Bug 1674342 as SharedArrayBuffer are not transferable.
Can you try to set dom.worker.console.dispatch_events_to_main_thread to false in about:config and check again ? (you might need to reload your page for the changes to be taken into account)

Depends on: 1674342
Flags: needinfo?(d)

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #20)

(In reply to DDR from comment #19)

This issue is still present in Firefox 111.0.1.

console.log(new ArrayBuffer(10)) //works
console.log(new SharedArrayBuffer(10)) //doesn't work

This is probably blocked on Bug 1674342 as SharedArrayBuffer are not transferable.
Can you try to set dom.worker.console.dispatch_events_to_main_thread to false in about:config and check again ? (you might need to reload your page for the changes to be taken into account)

Hi Nicholas. Thank you for your prompt response!

Reloading the page, I do see a change - nothing is logged from the workers now.

Flags: needinfo?(d)

(In reply to DDR from comment #21)

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #20)

(In reply to DDR from comment #19)

This issue is still present in Firefox 111.0.1.

console.log(new ArrayBuffer(10)) //works
console.log(new SharedArrayBuffer(10)) //doesn't work

This is probably blocked on Bug 1674342 as SharedArrayBuffer are not transferable.
Can you try to set dom.worker.console.dispatch_events_to_main_thread to false in about:config and check again ? (you might need to reload your page for the changes to be taken into account)

Hi Nicholas. Thank you for your prompt response!

Reloading the page, I do see a change - nothing is logged from the workers now.

uh oh. Can you share the page, or if not, a reduced version of it somewhere so I can investigate?

I can confirm that with the pref set to false, I can see logged sharedArrayBuffer (see https://ffx-devtools-shared-array-buffer-worker.glitch.me/)

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #22)

uh oh. Can you share the page, or if not, a reduced version of it somewhere so I can investigate?

OK, I've got up a minimal (5-line!) repro case up. The github readme has some pictures and a summary there too. 🙂

https://github.com/DDR0/Stardust/tree/log-issue-reproduction

(git clone https://github.com/DDR0/Stardust.git; cd Stardust; ./example_server.py or so ought to start it up for you)

Thank you for having a look!

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #23)

I can confirm that with the pref set to false, I can see logged sharedArrayBuffer (see https://ffx-devtools-shared-array-buffer-worker.glitch.me/)

With the pref set to true or false for me, I do not see a logged sharedArrayBuffer from https://ffx-devtools-shared-array-buffer-worker.glitch.me/.

I am running Firefox 111.0.1 on Linux (Debian 12).

I tried this on Windows 10, and I do see the logged sharedArrayBuffer when I set dom.worker.console.dispatch_events_to_main_thread to false there.

I tested it on linux and after flipping the pref and closing devtools + reloading the page + reopening devtools, I was able to see the logged sharedArrayBuffer

Oh. Following those instructions, it does show up for me. Sorry.

See Also: → 1860888
You need to log in before you can comment on or make changes to this bug.