Issue metadata
Sign in to add a comment
|
SharedArrayBuffers sent to webworkers exhausts memory and crashes tab.
Reported by
jacob.sm...@gmail.com,
Jan 14
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18312 Steps to reproduce the problem: See the attached file for implementation. 1. Create a webworker which posts an acknowledge string on every message received 2. Initialize and send a large SharedArrayBuffer to the webworker 3. Keep sending new SharedArrayBuffers on each acknowledge from the webworker 4. Observe that the tab process reaches 4GB of memory usage and crashes with "Aw, Snap!" 5. Reload the page and click the "Collect Garbage" button in the DevTools memory tab before the tab process reaches 4GB of memory usage. 6. observe that the page works fine as long as you manually garbage collect. What is the expected behavior? Chrome should garbage collect SharedArrayBuffers which are no longer used by the page or the webworkers automatically, instead of relying on the user clicking the "Collect Garbage" button in DevTools. What went wrong? SharedArrayBuffers sent to the webworker are not garbage collected. Did this work before? N/A Chrome version: 73.0.3670.0 Channel: canary OS Version: 10.0 Flash Version:
,
Jan 14
,
Jan 16
(6 days ago)
Thanks for filing the issue... @Reporter: It would be really helpful if a sample test file/URL is provided, so that we can investigate the issue further. Thanks.!
,
Jan 16
(6 days ago)
A minimal example reproducing the issue was attached to the original report. Please let me know if this is not enough.
,
Jan 16
(6 days ago)
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 17
(5 days ago)
jacob.smedegaard@ Thanks for the update. We cannot triage this issue with a .js file. Request you to provide a HTML file or a sample extension where this issue can be reproduced, which will help in further triaging. Thanks..
,
Jan 17
(5 days ago)
Hi Susan, Thank you for the quick reply :) I have attached a .html version of the test case. As an alternative, I have created a codepen which also reproduces the issue. https://codepen.io/anon/pen/PXvmdP
,
Jan 17
(5 days ago)
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 18
(4 days ago)
Able to reproduce the issue on chrome reported version# 73.0.3670.0, stable# 71.0.3578.98 and on latest chrome# 73.0.3674.0 with '.html' file provided in comment# 7 using Windows-10. As this issue is seen from M-60(60.0.3112.0), hence considering this issue as Non-Regression and marking it as Untriaged. Note: Issue is not seen on Mac 10.14.0 and Ubuntu 17.10. Thanks!
,
Jan 18
(4 days ago)
I was able to somewhat reproduce the issue running the index.html file on Ubuntu 18.04 with chrome version 70.0.3538.77 (Official Build) (64-bit).
At first it will throw a rangeError when trying to allocate a new buffer after it reaches 4GB memory usage.
Uncaught RangeError: Array buffer allocation failed
at new SharedArrayBuffer (<anonymous>)
at post (index.html:16)
at Worker.worker.addEventListener (index.html:24)
After about a minute Ubuntu will report that a chrome process has crashed. See Crash Report ID 88ee9a528c4f4ffb (Local Crash ID: Chrome).
Opening the Chrome DevTools at any point after the RangeError has occurred will cause the tab to crash with an "Aw,snap".
,
Jan 18
(4 days ago)
A co-worker has confirmed that eventually it will also crash on Mac using the stable release of Chrome.
,
Jan 21
(2 days ago)
Guessed that this is dup of issue 877055
,
Today
(21 hours ago)
herhut, can you please confirm #12?
,
Today
(20 hours ago)
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by wanderview@chromium.org
, Jan 14