SIGSEGV Segmentation fault when loading data URIs using import

[manen]

Version

v18.8.0

Platform

Linux manen 5.19.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 17 Aug 2022 13:48:51 +0000 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

node repl,

for(let i = 0; true; i++) {
  let buf = 'const a = "';
  for(let j = 0; j < i; j++) {
    buf += 'a';
  }
  buf += '";export default a;';
  const total = 'data:text/javascript;charset=utf-8,' + buf;
  console.log('trying', total.length);
  await import(total);
  console.log(total.length, 'successful');
}

this will load bigger and bigger modules using import, eventually failing

How often does it reproduce? Is there a required condition?

nope. will fail eventually

What is the expected behavior?

counting higher and higher, not failing at any number

What do you see instead?

this code will start counting up, and based on my experience it will fail somewhere around 2800-3400.

running the node repl using gdb:

Thread 1 "node" received signal SIGSEGV, Segmentation fault.
0x0000000000a79e4a in node::loader::ImportModuleDynamically(v8::Local<v8::Context>, v8::Local<v8::Data>, v8::Local<v8::Value>, v8::Local<v8::String>, v8::Local<v8::FixedArray>) [clone .cold.279] ()

Additional information

couldn't test it in raw chromium because Refused to load the script 'data:text/javascript;charset=utf-8,const a = "";export default a;' because it violates the following Content Security Policy directive: "script-src chrome://resources chrome://test chrome://webui-test 'self'". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

tested it in deno, it counted really slow, i let it count to ~5000 and it didn't fail.

not sure at all, but might be related to #35889, #43083, #44219. (yes i did just look import sigsegv up in the open issues)

[dnalborczyk]

thank you for filing the issue @manen !

I get the mentioned segmentation fault only as you described in the REPL, not if I run the code from a script. could you confirm?

What is the expected behavior?

counting higher and higher, not failing at any number

it will eventually fail as you will run out of memory, as modules are cached in node.js.

tested it in deno, it counted really slow, i let it count to ~5000 and it didn't fail.

I would imagine deno will eventually fail as well running out of memory.

[manen]

@dnalborczyk thanks for the response!

I get the mentioned segmentation fault only as you described in the REPL, not if I run the code from a script. could you confirm?

i only tested it in the repl, i don't know if it would reproduce in a script. sadly i'm not near my computer so i can't confirm.

it will eventually fail as you will run out of memory, as modules are cached in node.js.

wouldn't garbage collection take care of this? besides, i don't think that's the case because i originally stumbled upon this issue while trying to load the also ESM index script for one of my side projects, https://vanilla.manen.me/index.js only once, by fetching it, and inserting the text content into a data uri as seen in the example code. it's a fairly lightweight svelte app, so if node runs out of memory attempting to make space for this little script.

if the repl allocates a small chunk of memory for modules by default, that would explain it. i'll be sure to test it as soon as i'm near my computer again.

[dnalborczyk]

it will eventually fail as you will run out of memory, as modules are cached in node.js.

just to clarify, I meant if you run your code snippet (creating endless modules) in a loop. that failure tho is unrelated to your described seg fault.
it was just a reply to your expectation: counting higher and higher, not failing at any number.

wouldn't garbage collection take care of this?

no, every imported module remains in memory. the only thing being collected is any code (with potential side effects) in the top scope of the module which runs when you load a module. but even if your modules contain nothing but top level code with no exports you would run eventually out of memory, because of the module cache creating enough entries to hit the memory limit eventually.

not sure at all, but might be related to #35889, #43083, #44219. (yes i did just look import sigsegv up in the open issues)

you might be indeed hitting the above linked issues . if the REPL runs in the vm, it's very likely.

[legendecas]

Fixed by #48510. The script in OP can successfully run until out of memory.