"npx webpack" fails with "RangeError: WebAssembly.Instance(): Out of memory: wasm memory"

Bug report

What is the current behavior? Attempting to run webpack leads to the following error:

$ npm view webpack version
5.70.0
$ npx webpack
[webpack-cli] RangeError: WebAssembly.Instance(): Out of memory: wasm memory
    at create (/home/davedude/public_html/ConjunctionJunction/node_modules/webpack/lib/util/hash/wasm-hash.js:154:4)
    at module.exports (/home/davedude/public_html/ConjunctionJunction/node_modules/webpack/lib/util/createHash.js:160:27)
    at /home/davedude/public_html/ConjunctionJunction/node_modules/webpack/lib/DefinePlugin.js:289:22
    at _next31 (eval at create (/home/davedude/public_html/ConjunctionJunction/node_modules/tapable/lib/HookCodeFactory.js:19:10), <anonymous>:40:1)
    at _next9 (eval at create (/home/davedude/public_html/ConjunctionJunction/node_modules/tapable/lib/HookCodeFactory.js:19:10), <anonymous>:95:1)
    at Hook.eval [as call] (eval at create (/home/davedude/public_html/ConjunctionJunction/node_modules/tapable/lib/HookCodeFactory.js:19:10), <anonymous>:117:1)
    at Hook.CALL_DELEGATE [as _call] (/home/davedude/public_html/ConjunctionJunction/node_modules/tapable/lib/Hook.js:14:14)
    at Compiler.newCompilation (/home/davedude/public_html/ConjunctionJunction/node_modules/webpack/lib/Compiler.js:1109:26)
    at /home/davedude/public_html/ConjunctionJunction/node_modules/webpack/lib/Compiler.js:1153:29
    at Hook.eval [as callAsync] (eval at create (/home/davedude/public_html/ConjunctionJunction/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:4:1)

If the current behavior is a bug, please provide the steps to reproduce.

The issue first appeared in release 5.61:

$ npm install webpack@5.61 --save-dev --fund=false --audit=false

changed 1 package in 824ms
$ npx webpack
...same issue...

$ npm install webpack@5.60 --save-dev --fund=false --audit=false

changed 1 package in 891ms
$ npx webpack
assets by status 0 bytes [cached] 1 asset

WARNING in configuration
The 'mode' option has not been set, webpack will fallback to 'production' for this value.
Set 'mode' option to 'development' or 'production' to enable defaults for each environment.
You can also set it to 'none' to disable any default behavior. Learn more: https://webpack.js.org/configuration/mode/

ERROR in main
Module not found: Error: Can't resolve './src' in '/home/davedude/public_html/ConjunctionJunction'
resolve './src' in '/home/davedude/public_html/ConjunctionJunction'
  using description file: /home/davedude/public_html/ConjunctionJunction/package.json (relative path: .)
    Field 'browser' doesn't contain a valid alias configuration
    using description file: /home/davedude/public_html/ConjunctionJunction/package.json (relative path: ./src)
      no extension
        Field 'browser' doesn't contain a valid alias configuration
        /home/davedude/public_html/ConjunctionJunction/src doesn't exist
      .js
        Field 'browser' doesn't contain a valid alias configuration
        /home/davedude/public_html/ConjunctionJunction/src.js doesn't exist
      .json
        Field 'browser' doesn't contain a valid alias configuration
        /home/davedude/public_html/ConjunctionJunction/src.json doesn't exist
      .wasm
        Field 'browser' doesn't contain a valid alias configuration
        /home/davedude/public_html/ConjunctionJunction/src.wasm doesn't exist
      as directory
        /home/davedude/public_html/ConjunctionJunction/src doesn't exist

webpack 5.60.0 compiled with 1 error and 1 warning in 148 ms

The repro environment is an empty package, no src/ directory. (It dies before that matters.)

The issue appears to be strongly related to this blog post: https://blog.stackblitz.com/posts/debugging-v8-webassembly/, which indicates that a fix in v8 was needed (or coding differently, to create fewer Instances).

I first encountered this issue with Node v12.22.10 (which is listed as supported), which has a v8 version well before the fix landed.

I also tried Node v14.19.1, which is the latest version available from Debian. Same issue.

The commit in Node that fixes the issue in V8 is here: https://github.com/nodejs/node/commit/3e9939e38cb4ecc7c8a9bd7cff64baca3a897eb3

If I’m reading it right, that means this code only works with Node v17.2.0 or later. Or (more likely) there’s an additional repro condition I don’t know about.

What is the expected behavior?

Doesn’t crash.

Other relevant information: webpack version: 5.61+ Node.js version: v12.22.10, v14.19.1 Operating System: Debian/testing Additional tools:

[d0sboots]

If you put in ulimit -a, you should see something like this:

-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)         0
-m: resident set size (kbytes)      unlimited
-u: processes                       31275
-n: file descriptors                1024
-l: locked-in-memory size (kbytes)  1004968
-v: address space (kbytes)          unlimited
-x: file locks                      unlimited
-i: pending signals                 31275
-q: bytes in POSIX msg queues       819200
-e: max nice                        0
-r: max rt priority                 0
-N 15: rt cpu time (microseconds)   unlimited

If the values for -d (data seg size), -m (resident set size), or especially -v (address space) are not “unlimited”, that means you have a ulimit set and you’re probably having the same issue I did.

As to how to fix it, it’ll be set in the shell files… somewhere. Maybe your .profile, .bashrc, etc. Maybe the system version of the same. It depends on what shell you’re running, what OS/distribution, etc.

[d0sboots]

I found the issue.

V8 uses 10GB memory allocations in WASM to implement guard regions. Most of this memory is never committed (actually given pages by the VM system), but the virtual address space is still consumed.

I had a 5GB ulimit set, for safety. Once that was removed, everything worked fine.