Sitelet https://github.com/nodejs/node/issues/44438
Skip to content

SIGSEGV Segmentation fault when loading data URIs using import #44438

Closed
Closed
SIGSEGV Segmentation fault when loading data URIs using import#44438

Description

@manen
manen
opened on Aug 29, 2022

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)

Activity

  1. dnalborczyk commented on Aug 30, 2022

    @dnalborczyk
    dnalborczyk
    on Aug 30, 2022
    Contributor

    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.

  2. manen commented on Aug 31, 2022

    @manen
    manen
    on Aug 31, 2022
    Author

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

  3. dnalborczyk commented on Sep 8, 2022

    @dnalborczyk
    dnalborczyk
    on Sep 8, 2022
    Contributor

    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.

  4. legendecas commented on Oct 23, 2023

    @legendecas
    legendecas
    on Oct 23, 2023
    Member

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

  5. legendecas
    closed this as completedon Oct 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions