WebAssembly compilation consumes tons of memory, may never finish
Reported by
e...@limulus.net,
Jul 14
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1.1 Safari/605.1.15 Steps to reproduce the problem: 1. Unzip test case attachment. 2. Start a local server with the files. (The test case makes use of `fetch` to stream the .wasm binary, so needs real HTTP.) In other words, run `npx serve webassembly-compile-oom-testcase`. 3. Open the local server address in Chrome Beta. 4. Click the Start Compilation button. What is the expected behavior? The page should display “complete” relatively soon after clicking the button. What went wrong? It stays in the “compiling…” state, while the Chrome Helper process rapidly grows in size (100s of MBs a second). I have not waited longer than ~20 seconds to see if compilation ever completes. Did this work before? No Does this work in other browsers? Yes Chrome version: 68.0.3440.59 (Official Build) beta (64-bit) Channel: beta OS Version: OS X 10.13.5 Flash Version: 30.0.0.134 The .wasm file in the test case includes the PCRE2 library (https://pcre.org/), compiled using emscripten. It only creates this issue if `prcre2_match` or `pcre2_dfa_match` are called from within my C/JS glue code. I tested this in Dev and Canary as well, and things work as expected. So it seems V8 6.9 is immune. However, since this is something of DoS bug, I figured it was worth filing anyway, in case the fix should be backported. If you need more info, you can contact me here: eric@limulus.net
,
Jul 18
Unable to reproduce the issue on chrome reported version# 68.0.3440.59 using Mac 10.13.5 with steps mentioned below: 1) Launched chrome reported version and started a local server "http://localhost:8000" 2) Clicked on 'Start Compilation", seen 'failed: Failed to execute 'compile' on 'WebAssembly': Incorrect response MIME type. Expected 'application/wasm'.' @Reporter: Please find the attached screencast for your reference and let us know if we missed anything in reproducing the issue, provide your feedback on it which help in further triagign it. thanks!
,
Jul 18
Thanks for the screencast! It looks like that error is a result of your local server (`python -m SimpleHTTPServer`) not knowing to map files with the `.wasm` extension to the `application/wasm` MIME type. You'll need to have your local server use the correct content type header for this file in order to reproduce the issue with my test case. Are you able to install a reasonably recent version of Node.js? If so, my suggestion of running `npx serve webassembly-compile-oom-testcase` will serve the `.wasm` file with the correct content type header. Otherwise, I can rewrite my test case to avoid this issue. Thanks!
,
Jul 18
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
,
Jul 19
Tested the issue on chrome reported version# 68.0.3440.59 using Mac 10.13.1 on which we have node.js and NPM setup available, after following the steps mentioned in comment# 2, facing the same issue 'failed: Failed to execute 'compile' on 'WebAssembly': Incorrect response MIME type. Expected 'application/wasm'.' @Reporter: Could you please provide any alternate Test file/URL that reproduces the issue which helps us in further triaging it. Thanks!
,
Jul 19
Sure. I have reworked my test case so that it should not error when using `python -m SimpleHTTPServer` to serve it locally. Please give it another try. Thanks!
,
Jul 19
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
,
Jul 20
Able to reproduce the issue on reported version 68.0.3440.59 and latest beta# 68.0.3440.68 and the same is not seen on latest canary# 69.0.3396.0 using Windows 10, Ubuntu 14.04 & Mac 10.12.6, hence providing reverse bisect info Reverse Bisect Info: ================ Last Bad build: 69.0.3480.0 First Good build: 69.0.3381.0 You are probably looking for a change made after 572201 (known good), but no later than 572202 (first known bad). https://chromium.googlesource.com/chromium/src/+log/f7b526674131a74a43ba13394f1c4819cac9c2d2..9c5b03b905d0657f112da540c0b9c696cc9226ff V8 Change-Log: https://chromium.googlesource.com/v8/v8/+log/91a410dd..fe51067f Unable to find the correct suspect from the above change log, hence marking this issue as Untriaged and requesting someone from the Blink>Javascript team help us in assigning it to the correct owner. Adding ReleaseBlock-Stable for M-69, feel free to remove it if not applicable. Thanks!
,
Jul 25
clemensh@ can you please take a look at this M68 regression.
,
Jul 26
This is the interesting change: dbfb80f Reland^3 "[wasm] Enable Liftoff by default on ia32 and x64" by Clemens Hammacher · 3 weeks ago Liftoff (the new baseline compiler) usually consumes more memory, but in this case it might actually reduce peak memory consumption. We recently landed a few more changes to reduce peak memory consumption on M-69, but these are changes we can't merge back to M-68. Maybe we can throttle background compilation on M-68 to reduce peak memory consumption, but maybe this will really just be fixed by the changes we did in M-69. I can take another look next week.
,
Jul 26
Removing M-69 as this looks to be fixed in M-69 from chrome version 69.0.3481.0.
,
Jul 30
Friendly ping to get an update as stable release is coming soon and this bug is marked as RBS for M68. Thanks..!
,
Jul 31
It seems this is not a regression, thus removing blocker label.
,
Jul 31
,
Aug 8
Since 68 is out since two weeks now, and 69 will go stable in about four weeks, I think it's not worth trying to come up with a patch for 68. |
||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||
Comment 1 by viswa.karala@chromium.org
, Jul 17