SEGFAULT in REPL

[aduh95]

REPL crashes when doing a dynamic import when the working directory contains a folder with the name src:

$ mkdir repro
$ cd repro
$ mkdir src
$ node
Welcome to Node.js v16.1.0.
Type ".help" for more information.
> const fn = () => import('crypto')
undefined
> fn('')
Promise { <pending> }
> undefined
undefined
> fn('')
[1]    59895 segmentation fault  node
$ node_master
Welcome to Node.js v17.0.0-pre.
Type ".help" for more information.
> const fn = () => import('crypto')
undefined
> fn('')
[1]    59992 segmentation fault  ../../node/out/Release/node
$ node_master
Welcome to Node.js v17.0.0-pre.
Type ".help" for more information.
> const fn = () => import('crypto')
undefined
> fn('')
Promise { <pending> }
> fn('')
Promise { <pending> }
> fn('')
Promise { <pending> }
> fn('')
Promise { <pending> }
> fn('')
[1]    59997 segmentation fault  ../../node/out/Release/node

Here's the info given by lldb when the process crashes:

Process 59603 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x18)
    frame #0: 0x000000010008a952 node`node::loader::ImportModuleDynamically(v8::Local<v8::Context>, v8::Local<v8::ScriptOrModule>, v8::Local<v8::String>, v8::Local<v8::FixedArray>) + 489
node`node::loader::ImportModuleDynamically:
->  0x10008a952 <+489>: movq   0x18(%rax), %rcx
    0x10008a956 <+493>: movq   0x8(%rcx), %rax
    0x10008a95a <+497>: testq  %rax, %rax
    0x10008a95d <+500>: movq   -0x58(%rbp), %rbx
Target 0: (node) stopped.

The crash also happen with a module other than crypto.

Originally posted by @rayfoss in #38090 (comment)

[seangoedecke]

After a bit of digging I think it's the same problem as here: #25424

You can reproduce straightforwardly by creating a function like const fn = () => import('crypto'), runnning global.gc(), then trying to run fn(). The ContexifyScript wrapping import('crypto') gets GCd, the destructor removes that entry from id_to_script_map, then when fn() tries to read the map it segfaults.

[joyeecheung]

Closing as #48510 has landed and should fix this. We can re-open if that turns out to be incorrect (hopefully not).