Calling async function fn() { x = await import('fs'); }; fn() causes SIGSEGV in REPL

[nettybun]

• Version: Tested on v15.14.0 and v16.1.0 and v16.3.0
• Platform: Linux 5.8.0-53-generic Proposal: Comment all the code #60~20.04.1-Ubuntu x86_64
• Subsystem: VM? ESM?

What steps will reproduce the bug?

$ node
Welcome to Node.js v15.14.0.
Type ".help" for more information.
> async function fn() { x = await import('fs') }
undefined
> fn()
fish: “node” terminated by signal SIGSEGV (Address boundary error)

In v15.14.0 the x = part is required to cause the crash. In v16+ it seems this happens even without the variable assignment:

$ node
Welcome to Node.js v16.1.0.
Type ".help" for more information.
> async function fn() { import('fs') }
undefined
> fn()
fish: “node” terminated by signal SIGSEGV (Address boundary error)

$ node
Welcome to Node.js v16.1.0.
Type ".help" for more information.
> async function fn() { await import('fs') }
undefined
> fn()
fish: “node” terminated by signal SIGSEGV (Address boundary error)

Oddly enough it's sometimes ok? Once?

$ node
Welcome to Node.js v16.3.0.
Type ".help" for more information.
> async function fn() { await import('fs') }
undefined
> fn()
Promise { <pending> }
> fn()
fish: “node” terminated by signal SIGSEGV (Address boundary error)

It says Promise { <pending> } but it seems lucky?

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

Most of the time... I only have a Linux machine here so limited testing.

What is the expected behavior?

No SIGSEGV

What do you see instead?

SIGSEGV

Additional information

I tried looking up how to get a coredump, here's the closest I got:

$ npm i segfault-handler
$ node
Welcome to Node.js v16.1.0.
Type ".help" for more information.
> async function fn() { tt = await import('fs') }
undefined
> const SegfaultHandler = require('segfault-handler');
undefined
> SegfaultHandler.registerHandler('crash.log');
undefined
> fn()
PID 49713 received SIGSEGV for address: 0x10
/home/today/_/work/acorn-macros/node_modules/segfault-handler/build/Release/segfault-handler.node(+0x3785)[0x7f5e72cf1785]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7f5e729803c0]
node[0xa2dbb2]
node(_ZN2v88internal7Isolate38RunHostImportModuleDynamicallyCallbackENS0_6HandleINS0_6ScriptEEENS2_INS0_6ObjectEEENS0_11MaybeHandleIS5_EE+0xad)[0xe7a9bd]
node(_ZN2v88internal25Runtime_DynamicImportCallEiPmPNS0_7IsolateE+0xc8)[0x1237528]
node[0x160c794]
fish: “node” terminated by signal SIGSEGV (Address boundary error)

[Ayase-252]

Duplicate of #38695?

[aduh95]

Duplicate of #38695?

Looks like it. @heyheyhello do you happen to have a folder with the name src in the directory you're working in?

[RaisinTen]

@aduh95 I could reproduce this and also the code in #38695 on v16.0.0 without having to create any src directory in the current working directory.

[aduh95]

@aduh95 I could reproduce this and also the code in #38695 on v16.0.0 without having to create any src directory in the current working directory.

Ah it did seem indeed a bit superstitious to think it was part of the repro. Thanks for the confirmation.

Closing as duplicate.

[nettybun]

Yeah there's no src directory :) Thanks everyone!