Repository navigation
Potential Wasm execution limits in some low-memory environments #40201
Description
Activity
Note this is not lexer specific - it is simply being unable to intialize the Web Assembly module at all. The only requirement on Wasm memory in the lexer is a 13KB stack size requirement.
Any idea about how low the memory needs to be? I'd like to try to reproduce with Docker.
That would be great to try. I was able to get them to give a report in nodejs/cjs-module-lexer#61 (comment).
The stackoverflow listing for this is also getting traffic - https://stackoverflow.com/questions/68991747/rangeerror-webassembly-instantiate-out-of-memory-wasm-memory.
I'm unable to reproduce with Docker.
Tried with
docker run --memory=6m image node app.mjs(the minimum that Docker allows).My test case is:
// app.mjs import { value } from './module.cjs'; console.log(value);
// module.cjs exports.value = 42;
Edit: I used the latest
node:12official image.Reacted by Guy BedfordIt seems to be some kind of interaction specifically in these types of virtual hosting environments. Perhaps a v8 bug?
Thanks so much for verifying the memory case, that's great to know! cjs-module-lexer reuses its heap for all analyses since they are sync so cleaned on each run it's just the Wasm instantiation specifically to worry about here.
Last I checked, for WASM it's particularly relevant to look at the virtual memory size limit, not (just) the actual RSS limit (which is what most people would refer to as "the memory limit"), because V8 reserves (but not actually allocated) large ranges of memory for WASM.
@addaleax thanks for the info, what debugging commands would you suggest I ask for while this replication is still current?
@guybedford I’m not sure, but you can check the virtual memory limit/set it through
ulimit -v.Seems this Twitter thread is closely related - https://twitter.com/_rvidal/status/1442868528068108289?s=20.
And Chromium issue - https://bugs.chromium.org/p/v8/issues/detail?id=12076
Another case - sveltejs/kit#2551.
If this turns out to be a bigger problem, I recently compiled es-module-lexer to asm.js with similar performance. We could make a special Node.js patch for 12 with asm.js instead of Wasm to avoid the issue. It would be a little bit of a process but could be an option if this is deemed worth the effort. Let's keep an eye on it...
Not sure if this can help but I was able to reproduce this with docker (by setting
ulimit -v <n>before running). I noticed the issue appeared starting inNode v12.22.0. I didn't encounter the said problem inNode v12.21.0and below.I'm having this issue as well.
@guybedford Did this affect any later Node.js release lines than 12? Node.js 12 is now End-of-Life and won't be getting further updates.
- changed the title
[-]Node.js 12 potential Wasm execution limits in some low-memory environments[/-][+]Potential Wasm execution limits in some low-memory environments[/+]on May 5, 2022 @richardlau there was actually a Node.js 14 report in nodejs/cjs-module-lexer#61 (comment), so it may be worth keeping this open.
Reacted by Richard Lau@mmgoodnow thanks! tried it out and it didnt crash
- added a commit that references this issue
on Dec 26, 2022
Version
12
Platform
?
Subsystem
No response
What steps will reproduce the bug?
I'm getting a few reports in nodejs/cjs-module-lexer#61 (comment) that cpanel environments running Node.js 12 may be hitting a Wasm out of memory issue in the Wasm allocation requirements for the lexer.
It is worth keeping an eye on these issues from a reliability perspective.
Note this path is only hit when importing CommonJS from an ES module for the first time as well, so it won't be soon on all boots but only as users adopt ES modules.
How often does it reproduce? Is there a required condition?
It seems to be very low memory environments.
What is the expected behavior?
No response
What do you see instead?
WebAssembly.instantiate throwing an out of memory error.
Additional information
No response