Menu
I've stumbled across some weird behavior in all browsers I've tried:
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
802
WebAssembly Now Supported across All Browsers.
The WebAssembly. Memory object is a resizable ArrayBuffer or SharedArrayBuffer that holds the raw bytes of memory accessed by a WebAssembly. Instance . Both WebAssembly and JavaScript can create Memory objects.
While WebAssembly runtimes do an excellent job of isolating the memory instances of different instances, within their own linear memories, WebAssembly modules are not safe from memory vulnerabilities, such as buffer overflow, or use-after-free.
wasm : Create a new XMLHttpRequest() instance, and use its open() method to open a request, setting the request method to GET , and declaring the path to the file we want to fetch. The key part of this is to set the response type to 'arraybuffer' using the responseType property.
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?
107
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
