Repository navigation
Closed as not planned
Labels
v8 engineIssues and PRs related to the V8 dependency.Issues and PRs related to the V8 dependency.wasmIssues and PRs related to WebAssembly.Issues and PRs related to WebAssembly.
Description
Version
v19.1.0
Platform
Linux Nugine-Ub2 5.15.0-52-generic #58-Ubuntu SMP Thu Oct 13 08:03:55 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Subsystem
No response
What steps will reproduce the bug?
Dependencies:
- Rust toolchain (nightly, 2022-11-14)
- just (https://github.com/casey/just)
- wasm-pack (https://github.com/rustwasm/wasm-pack)
git clone https://github.com/Nugine/simd.git -b main
cd simd
git checkout 508bffc65c3b72b889666773fe3e30a2b5a329f4
cd crates/hex-simd
just wasm-testI uploaded artifacts here for convenience: wbg_tmp.tar.gz
tar xvf wbg_tmp.tar.gz
cd wbg_tmp
ulimit -v 4000000 # 4GB
node run.js/home/nugine/tests/nodejs-wasm-oom/wbg-tmp/wasm-bindgen-test.js:716
const wasmInstance = new WebAssembly.Instance(wasmModule, imports);
^
RangeError: WebAssembly.Instance(): Out of memory: Cannot allocate Wasm memory for new instance
at Object.<anonymous> (/home/nugine/tests/nodejs-wasm-oom/wbg-tmp/wasm-bindgen-test.js:716:22)
at Module._compile (node:internal/modules/cjs/loader:1205:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1259:10)
at Module.load (node:internal/modules/cjs/loader:1068:32)
at Module._load (node:internal/modules/cjs/loader:909:12)
at Module.require (node:internal/modules/cjs/loader:1092:19)
at require (node:internal/modules/cjs/helpers:103:18)
at Object.<anonymous> (/home/nugine/tests/nodejs-wasm-oom/wbg-tmp/run.js:3:22)
at Module._compile (node:internal/modules/cjs/loader:1205:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1259:10)
Node.js v19.1.0
How often does it reproduce? Is there a required condition?
Always
What is the expected behavior?
It should work without OOM.
What do you see instead?
Nodejs allocates too much memory until OOM.
Additional information
Metadata
Metadata
Assignees
Labels
v8 engineIssues and PRs related to the V8 dependency.Issues and PRs related to the V8 dependency.wasmIssues and PRs related to WebAssembly.Issues and PRs related to WebAssembly.
Activity
bnoordhuis commentedon Nov 29, 2022
Guess no one else is going to pick this up? I can't try myself right now but does it work with the
--jitlessflag? V8's JIT makes fairly large reservations for WASM code. It's possible you're hitting a resource limit.Nugine commentedon Nov 29, 2022
bnoordhuis commentedon Nov 29, 2022
Failing with a 12 GB virtual memory limit isn't surprising. V8 allocates really large guard pages for performance reasons. See #45557 for a similar bug report.
Nugine commentedon Nov 29, 2022
I look into the process status before it gets killed. VmRSS is huge. Is it the expected behavior?
It's quite weird that nodejs allocates too much memory after the wasm code is finished. I still think this hehavior may be a bug.
bnoordhuis commentedon Nov 29, 2022
That's indeed quite high. It could be the JS heap (not WASM), it maxes out at 1.4 GB unless you raise the limit.
As a bit of expectation management: WASM is handled by V8, not node, so if there is a bug, you're going to have to report it upstream.
With that out of the way, it'd be good to test WASM-related flags. See
node --v8-options. For example,--liftoff-onlylets you check if the problem is in TurboFan, the optimizing compiler (visible in the stack trace above.)Nugine commentedon Nov 30, 2022
So the problem is in TurboFan.
I have submitted a issue to v8: https://bugs.chromium.org/p/v8/issues/detail?id=13543
bnoordhuis commentedon Nov 30, 2022
I'd include more details in the bug report if I were you, makes it more likely to get triaged quickly.
I'll close out this bug report as there isn't anything for node to do at this time.