Out of memory: Cannot allocate Wasm memory for new instance (after update from 1.100.3 to 1.101)

[JP95Git]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.101
• OS Version: Windows 11

Steps to Reproduce:

1. Having a working vscode 1.100.3 with remote connection to a linux server - everything works, no errors
2. Let vscode update to 1.101 - no problem so far
3. Let vscode update the code on the remote server - you'll get the error as seen here: Out of memory: Cannot allocate Wasm memory for new instance vscode-remote-release#11027

[deepak1556]

Based on microsoft/vscode-remote-release#11027 (comment), the error happens from llhttp wasm instantiation from undici

• Between 1.100 and 1.101 there is Node.js version bump from 20.19.0 to 22.15.1
• There is only a patch update to undici across these two versions and changeset doesn't show anything changed on this wasm module side, so definitely a new requirement from v8
• Tested the following minimal script https://gist.github.com/deepak1556/3576bbc59aebb253d6d433f6c7bf15b4 and confirmed the memory usage via pmap after instantiating the wasm module

v20.19.0

53167:   ./out/Release/node
Address           Kbytes     RSS   Dirty Mode  Mapping
00005ae544200000    9664    7936       0 r---- node
00005ae544b70000   29024   23072       0 r-x-- node
00005ae546800000       4       0       0 r-x-- node
00005ae546801000   46636    9276       0 r---- node
00005ae54958c000    1044    1044    1044 r---- node
00005ae549691000     124     112     112 rw--- node
...
00007beef0000000 2097152       0       0 -----   [ anon ]
00007bef70000000     128      12      12 rw---   [ anon ]
00007bef70020000 8388480       0       0 -----   [ anon ]
...
---------------- ------- ------- ------- 
total kB         11521052   54512    9552

v22.15.1

5376:   ./vscode-server-linux-arm64/node
Address           Kbytes     RSS   Dirty Mode  Mapping
0000000000400000   97836   40908       0 r-x-- node
000000000639c000      16      16       8 r---- node
00000000063a0000     260     252     112 rw--- node
...
0000fffcf0000000 2097152       0       0 -----   [ anon ]
0000fffd70020000 8388480       0       0 -----   [ anon ]
...
---------------- ------- ------- ------- 
total kB         11272500   55548   11308

[deepak1556]

My previous measurement was incorrect, the 10GB (2GB + 8GB) mapping is present in both versions, this comes from the memory32 wasm guard regions.

In both versions, Node.js does enable V8 wasm trap handlers https://github.com/nodejs/node/blob/bb1a61d8737feff534bb85368dab3b7c554c863d/src/node.cc#L1224-L1251 which is a prerequisite for enabling guard regions when allocating array buffer backing stores.

#if V8_ENABLE_WEBASSEMBLY
  bool guards = wasm_memory == WasmMemoryFlag::kWasmMemory32 &&
                trap_handler::IsTrapHandlerEnabled();
#else

Without the guard regions the allocation only performs whatever byte capacity the wasm needed via GetReservationSize https://github.com/nodejs/node/blob/bb1a61d8737feff534bb85368dab3b7c554c863d/deps/v8/src/objects/backing-store.cc#L81-L93.

Node.js can be started with --disable-wasm-trap-handler to trade the guard regions for slower runtime performance of wasm as documented in https://nodejs.org/en/blog/release/v20.15.0#cli-allow-running-wasm-in-limited-vmem-with---disable-wasm-trap-handler

[deepak1556]

I am unable to spot an increased memory usage when instantiating the wasm with my minimal test case so there must be something else I missed. In the meantime, users hitting this issue can set NODE_OPTIONS="--disable-wasm-trap-handler" environment variable in their remote server as a workaround to reduce memory usage.

[song83244829]

I am unable to spot an increased memory usage when instantiating the wasm with my minimal test case so there must be something else I missed. In the meantime, users hitting this issue can set NODE_OPTIONS="--disable-wasm-trap-handler" environment variable in their remote server as a workaround to reduce memory usage.

I can confirm this workaround works for me.

[mdeberts]

I am unable to spot an increased memory usage when instantiating the wasm with my minimal test case so there must be something else I missed. In the meantime, users hitting this issue can set NODE_OPTIONS="--disable-wasm-trap-handler" environment variable in their remote server as a workaround to reduce memory usage.

Where should I set NODE_OPTIONS="--disable-wasm-trap-handler" ?
Inside VsCode?

[deepak1556]

Michael Debertshäuser (@mdeberts) in your remote environment that any process can inherit from /etc/profile etc