You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Potential Wasm execution limits in some low-memory environments #40201
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.
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.
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.
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 in Node v12.22.0. I didn't encounter the said problem in Node v12.21.0 and below.
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
Activity
guybedford commentedon Sep 24, 2021
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.
targos commentedon Sep 24, 2021
Any idea about how low the memory needs to be? I'd like to try to reproduce with Docker.
guybedford commentedon Sep 24, 2021
That would be great to try. I was able to get them to give a report in nodejs/cjs-module-lexer#61 (comment).
guybedford commentedon Sep 24, 2021
The stackoverflow listing for this is also getting traffic - https://stackoverflow.com/questions/68991747/rangeerror-webassembly-instantiate-out-of-memory-wasm-memory.
targos commentedon Sep 24, 2021
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:
Edit: I used the latest
node:12official image.guybedford commentedon Sep 24, 2021
It seems to be some kind of interaction specifically in these types of virtual hosting environments. Perhaps a v8 bug?
guybedford commentedon Sep 24, 2021
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.
addaleax commentedon Sep 25, 2021
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.
guybedford commentedon Sep 26, 2021
@addaleax thanks for the info, what debugging commands would you suggest I ask for while this replication is still current?
addaleax commentedon Sep 27, 2021
@guybedford I’m not sure, but you can check the virtual memory limit/set it through
ulimit -v.guybedford commentedon Sep 29, 2021
Seems this Twitter thread is closely related - https://twitter.com/_rvidal/status/1442868528068108289?s=20.
guybedford commentedon Sep 29, 2021
And Chromium issue - https://bugs.chromium.org/p/v8/issues/detail?id=12076
guybedford commentedon Oct 8, 2021
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...
sianlasaga commentedon Dec 10, 2021
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.asheroto commentedon Feb 21, 2022
I'm having this issue as well.
richardlau commentedon May 5, 2022
@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.
[-]Node.js 12 potential Wasm execution limits in some low-memory environments[/-][+]Potential Wasm execution limits in some low-memory environments[/+]guybedford commentedon 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.
mmgoodnow commentedon Jul 26, 2022
seems this has been fixed as of v18.6.0 - #43612
pandyama commentedon Dec 21, 2022
@mmgoodnow thanks! tried it out and it didnt crash
fix: attempt to fix intense memory usage