Issue metadata
Sign in to add a comment
|
"Unable to deserialize cloned data" when receiving SharedArrayBuffer in Worklet (linux only)
Reported by
machtin....@gmail.com,
Feb 7 2018
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/64.0.3282.119 Chrome/64.0.3282.119 Safari/537.36 Steps to reproduce the problem: 1. open chrome://flags 2. make sure that both "Experimental enabled SharedArrayBuffer support in JavaScript" and "Experimental Web Platform features" are enabled. 3. open developer tools 4. in sources tab, make sure that "pause on uncaught exceptions" is checked 5. run the attached example (Also available at https://next.audiotool.com/worklet-bug/) The example starts a worklet and sends a message containing a shared array buffer to the worklet. What is the expected behavior? The Worklet should be able to access the data property of the MessageEvent. What went wrong? As soon as MessageEvent.data property is accessed on the receiving side, an error "Unable to deserialize cloned data" is thrown. After that, no further messages are dispatched. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 64.0.3282.140 Channel: stable OS Version: 4.13.0-32-generic Flash Version: Note that this works fine under Mac OS X using the same build of Chrome (64.0.3282.140)! Messages that do not contain SharedArrayBuffers do not cause this problem.
,
Feb 7 2018
binji@ might have some insight on this. The issue is related to the implementation of MessagePort + SharedArrayBuffer - AudioWorklet is a customer of both features. Confirmed the repro case works fine on Canary OSX. I also think this might be relevant: https://bugs.chromium.org/p/chromium/issues/detail?id=716320
,
Feb 7 2018
,
Feb 7 2018
Yes, Malcolm is working on adding support for this feature. See https://chromium-review.googlesource.com/c/chromium/src/+/854240 for a recent CL.
,
Feb 7 2018
Per #4: This will be fixed by the resolution of the issue 650937 , so I am marking this as duplicate.
,
Feb 9 2018
Hi hongchan, are you sure that issue #650937 (which is a CSS rendering bug) is related to this, or did you link the wrong issue?
,
Feb 26 2018
I can reproduce the same issue on Version 64.0.3282.186 (Official Build) (64-bit) Mac
,
Feb 26 2018
This will be resolved when we have a complete implementation of MessagePort support for SharedArrayBuffer.
,
Mar 29 2018
andre.michelle@ machtin.below@ This issue is fixed when "Experimental enabled SharedArrayBuffer support in JavaScript" flag is enabled. Right?
,
Apr 20 2018
andre.michelle@ machtin.below@ Ping - I'll wait one more week.
,
Apr 20 2018
In chrome 66, the original issue seems to be fixed (the SharedArrayBuffer can be received without the deserialization error). However, the example supplied in this report causes the tab to hang, when the page is refreshed 2-3 times (reproducibly). Shall I file a different bug for this?
,
Apr 20 2018
Could you try it with the latest Canary first? I think the hang issue is fixed in M67.
,
Apr 27 2018
The NextAction date has arrived: 2018-04-27
,
Apr 27 2018
Canary is not available for linux, but this is still reproducible in Chrome Unstable, Version 66.0.3346.8 (Official Build) dev (64-bit)
,
Apr 27 2018
Which issue are we talking about? The MessagePort or the browser hang? https://omahaproxy.appspot.com/ says all three channels should be M67. Like I mentioned in #12, the fix is in M67. I think you can update the browser or use the dev channel.
,
Apr 28 2018
Works with latest dev. Thanks!
,
Apr 28 2018
Per #11, the original issue is fixed. Closing. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by machtin....@gmail.com
, Feb 7 2018