Potential Wasm execution limits in some low-memory environments

[guybedford]

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

[guybedford]

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]

Any idea about how low the memory needs to be? I'd like to try to reproduce with Docker.

[guybedford]

That would be great to try. I was able to get them to give a report in nodejs/cjs-module-lexer#61 (comment).

[guybedford]

The stackoverflow listing for this is also getting traffic - https://stackoverflow.com/questions/68991747/rangeerror-webassembly-instantiate-out-of-memory-wasm-memory.

[targos]

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.

[guybedford]

It seems to be some kind of interaction specifically in these types of virtual hosting environments. Perhaps a v8 bug?

[guybedford]

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]

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]

@addaleax thanks for the info, what debugging commands would you suggest I ask for while this replication is still current?

[addaleax]

@guybedford I’m not sure, but you can check the virtual memory limit/set it through ulimit -v.

[guybedford]

Seems this Twitter thread is closely related - https://twitter.com/_rvidal/status/1442868528068108289?s=20.

[guybedford]

And Chromium issue - https://bugs.chromium.org/p/v8/issues/detail?id=12076

[guybedford]

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]

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.

[asheroto]

I'm having this issue as well.

[richardlau]

@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.

[guybedford]

@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]

seems this has been fixed as of v18.6.0 - #43612

[pandyama]

@mmgoodnow thanks! tried it out and it didnt crash