On Sun, Dec 02, 2018 at 10:23:14AM -0500, Bryan Steele wrote: > In -current (and 6.4), chrome repeatedly attempts to mmap a large linear > area of memory for WASM/WebAssembly and it always fails. WASM JIT avoids > using the system malloc/free, opting instead for their own "Heartbleed > accelerating custom allocator". > > Despite the horribleness, this feature is being increasingly used by > default if the browser advertises this misfeature as supported, many > sites will fallback if it is unavailable. Unfortunately, they *DO NOT* > fallback if WASM fails to allocate memory. You simply get broken, half- > working websites. :-( > > For example, the popular video streaming platform (twitch.tv) will show > a black box where the stream should be. The error is not obvious unless > you check the browsers Javascript console: > > Uncaught RangeError: WebAssembly.Memory(): could not allocate memory > at wasmworker.min.js:51 > at blob:https://www.twitch.tv/2af8520d-25ad-4f42-bc94-497265c25c62:6 > (index):1 Script error > > After hours of searching, I found the magic knob to disable WASM in > chrome: '--js-flags=--noexpose_wasm' > > There's no UI way that I can find to disable it, so you'll need to > add a shell alias or put it in your window managers config. > > Note: Firefox is also not saved from this insanity, WASM will often > fail there as well.. unless datasize is cranked to infinity and beyond.
For firefox, there's two things to frob if you want to debug this: - www/mozilla-firefox/patches/patch-js_src_jit_ProcessExecutableMemory_h clamps it to work with the default ulimits. Adapt the surrounding code to depend on the limits at runtime ? I wouldnt do this before consulting upstream first. - (i guess) twiddle javascript.options.wasm in about:config to stop advertising wasm as 'supported' ? If that improves things, i'll gladly change the default. Landry
