Why can't I construct `WebAssembly.Memory` in browsers?

Question

I've stumbled across some weird behavior in all browsers I've tried:

• Chromium 69.0.3497.92 (Official Build) Arch Linux (64-bit)
• Chrome 69.0.3497.100 (Official Build) (64-bit)
• Firefox 62.0 (64-bit)

When I try to allocate memory for WebAssembly by instantiating a WebAssembly.Memory object, for example like this:

new WebAssembly.Memory({ initial: 1 })

In Chrome/Chromium, I get:

VM274:1 Uncaught RangeError: WebAssembly.Memory(): could not allocate memory
    at <anonymous>:1:1
(anonymous) @ VM274:1

And in Firefox, I get:

Error: out of memory 

The allocation works just fine in Node.js, but for some reason, all my browsers fail here. I'm not sure what to do, and all sites that depend on WebAssembly have since become unusable for me.

I suspect Linux is preventing the browsers (but not node.js?) from allocating the memory, but that's just a wild guess. A near identical installation on another computer works just fine, but on this particular machine, every allocation from a browser fails.

Does anyone know what's going on?

Here's my output of ulimit -a:

-t: cpu time (seconds)              unlimited
-f: file size (blocks)              unlimited
-d: data seg size (kbytes)          unlimited
-s: stack size (kbytes)             8192
-c: core file size (blocks)         unlimited
-m: resident set size (kbytes)      unlimited
-u: processes                       31215
-n: file descriptors                1024
-l: locked-in-memory size (kbytes)  16384
-v: address space (kbytes)          8388608
-x: file locks                      unlimited
-i: pending signals                 31215
-q: bytes in POSIX msg queues       819200
-e: max nice                        0
-r: max rt priority                 99
-N 15:                              unlimited

Answer 1

This sounds like a limit that's set in your OS. On 64-bit systems, the browsers reserve 6GB of virtual memory per wasm memory object (in order to avoid bounds checks in the machine code). If your max memory is limited you may run into problems with that. The output from ulimit shows that you're limited to 8GB of virtual address space per process, which probably explains this.

Perhaps try running ulimit -v unlimited to see if this improves the situation?