WASM/WebAssembly is busted

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

WASM/WebAssembly is busted

Bryan Steele
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.

-Bryan.

Here's the ktrace(1)/kdump(1) for chrome:

 60738 chrome   CALL  mmap(0x1f46f5fa0000,0x280000000,0<PROT_NONE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
 60738 chrome   CALL  mmap(0x1f46f5fa0000,0x280000000,0<PROT_NONE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
 60738 chrome   CALL  mmap(0x208a1b2f0000,0x280000000,0<PROT_NONE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
 60738 chrome   CALL  mmap(0x208a1b2f0000,0x280000000,0<PROT_NONE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
 60738 chrome   CALL  mmap(0x2f8546810000,0x280000000,0<PROT_NONE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
 60738 chrome   CALL  mmap(0x2f8546810000,0x280000000,0<PROT_NONE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
 60738 chrome   CALL  mmap(0x29b16e690000,0x280000000,0<PROT_NONE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
 60738 chrome   CALL  mmap(0x29b16e690000,0x280000000,0<PROT_NONE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
 60738 chrome   CALL  mmap(0x2cfe5ed40000,0x280000000,0<PROT_NONE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
 60738 chrome   CALL  mmap(0x2cfe5ed40000,0x280000000,0<PROT_NONE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
 60738 chrome   CALL  mmap(0x2b67a9e90000,0x280000000,0<PROT_NONE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
 60738 chrome   CALL  mmap(0x2b67a9e90000,0x280000000,0<PROT_NONE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory

Reply | Threaded
Open this post in threaded view
|

Re: WASM/WebAssembly is busted

Landry Breuil-5
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

Reply | Threaded
Open this post in threaded view
|

Re: WASM/WebAssembly is busted

Robert Nagy
On 02/12/18 16:53 +0100, Landry Breuil wrote:

> 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
>

Well WASM cannot allocate memory even with 8G of data limit and the max size
in v8 is 2G, so something else is wrong as well.