Segmentation fault with `import()` instead of calling `importModuleDynamically`

[nicolo-ribaudo]

• Version: 14.15.0, 15.0.1. It doesn't crash with 12.9.0.
• Platform: Linux nicolo-XPS-15-9570 5.4.0-52-generic #57-Ubuntu SMP Thu Oct 15 10:57:00 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
• Subsystem: vm

What steps will reproduce the bug?

https://github.com/nicolo-ribaudo/babel/tree/node-segfault

I'm sorry but I can't create a smaller reproduction example (EDIT: #35889 (comment)): I managed to create a small test that reproduces the crash almost always, but it still far from being "self contained".

1. Run make bootstrap to install dependencies and compile everything
2. Run node --experimental-vm-modules ./node_modules/.bin/jest -i babel-core/test/segfault to see the segfault (try 2-3 times, sometimes the first run doesn't fail).

That test will run this file: I have placed a debugger; statement so that you can --inspect-brk it. After debugger, if you move into the import() call, it will crash.

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

Almost 100%

What is the expected behavior?

import() should call Jest's importModuleDynamically function.

What do you see instead?

@SimenB tried debugging this segfault and extracted this stacktrace (babel/babel#12288 (comment)):

PID 43445 received SIGSEGV for address: 0x0
0   segfault-handler.node               0x00000001055e3fa0 _ZL16segfault_handleriP9__siginfoPv + 304
1   libsystem_platform.dylib            0x00007fff6951f5fd _sigtramp + 29
2   ???                                 0x0000000000000007 0x0 + 7
3   node                                0x000000010033df4a _ZN2v88internal7Isolate38RunHostImportModuleDynamicallyCallbackENS0_6HandleINS0_6ScriptEEENS2_INS0_6ObjectEEE + 138
4   node                                0x00000001006f82f4 _ZN2v88internal25Runtime_DynamicImportCallEiPmPNS0_7IsolateE + 340
5   node                                0x0000000100a797b4 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvInRegister_NoBuiltinExit + 52
[1]    43445 segmentation fault  node --experimental-vm-modules --inspect-brk ./node_modules/.bin/jest 

Additional information

• When the test doesn't crash, it throws that file:///home/nicolo/Documenti/dev/babel/babel/packages/babel-core/test/fixtures/example.mjs doesn't exist even if it does. However, this might be caused by Jest?
• If you can't reproduce the bug, you can try running node --experimental-vm-modules ./node_modules/.bin/jest -i babel-core/test/config-chain which is how I originally discovered this issue. You can stop right before crashing by adding a debugger; right before the compiled version (which will be generated in packages/babel-core/lib/config/files/import.js) of this import() call.

Similar bugs

• Segfault importing ESM module twice #33233 is a segfault when using import(), but I don't think that it is the same bug because that one only happens in the REPL.
• vm: Script importModuleDynamically memory leak #25424 This is calling importModuleDynamically before crashing, while in my case I don't think it is.

[SimenB]

• When the test doesn't crash, it throws that file:///home/nicolo/Documenti/dev/babel/babel/packages/babel-core/test/fixtures/example.mjs doesn't exist even if it does. However, this might be caused by Jest?

Yes, Jest doesn't deal with file URLs, that's a bug that should be simple to fix. I can fix that right away.

EDIT: jestjs/jest#10744

@nicolo-ribaudo "Subsystem" is vm, btw

EDIT2: For anyone looking into this, the importModuleDynamically call is implemented here: https://github.com/facebook/jest/blob/2b748f67c25615a111330017a2bffc0baf51d558/packages/jest-runtime/src/index.ts#L1176-L1182

[SimenB]

@devsnek sorry to ping you, but do you have any idea of the top of your head for what we could be doing wrong in Jest? It's probably something that should be tweaked in Node regardless since it segfaults, but I'm also quite certain it's Jest doing something unexpected 🙂

[nicolo-ribaudo]

If it helps, I created a minimal (almost, it still uses Jest) reproduction: https://github.com/nicolo-ribaudo/node-segfault-jest-dynamic-import

Also @bmeck kindly told me that this is probably a known v8 issue, but I couldn't find it in the v8 bug tracker 😅

---

EDIT: I created a minimal reproduction without any dependency, but it's the first time I use the vm module so I might have done something wrong. https://github.com/nicolo-ribaudo/node-vm-dynamic-import-segfault

[bmeck]

It is from the VM module dealing with https://bugs.chromium.org/p/v8/issues/detail?id=10284 , which means that these fake modules from source text alone don't get properly resolved and it segfaults

[daniele-orlando]

I can reproduce this bug on Node v16.9.1 using Webpack and Babel configured with ESM configuration files.

PID 19496 received SIGSEGV for address: 0x18
0   segfault-handler.node               0x0000000105b630aa _ZL16segfault_handleriP9__siginfoPv + 298
1   libsystem_platform.dylib            0x00007fff20399d7d _sigtramp + 29
2   ???                                 0x00002afc24f31c6b 0x0 + 47262440037483
3   node                                0x000000010314ada6 _ZN2v88internal7Isolate38RunHostImportModuleDynamicallyCallbackENS0_6HandleINS0_6ScriptEEENS2_INS0_6ObjectEEENS0_11MaybeHandleIS5_EE + 218
4   node                                0x000000010340c3de _ZN2v88internal25Runtime_DynamicImportCallEiPmPNS0_7IsolateE + 329
5   node                                0x0000000103696b54 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvInRegister_NoBuiltinExit + 52
6   node                                0x00000001037223ce Builtins_CallRuntimeHandler + 78
7   node                                0x0000000103629fea Builtins_InterpreterEntryTrampoline + 202
zsh: segmentation fault  node --trace-event-categories v8,node,node.async_hooks 

[devsnek]

v8 has landed a partial fix for this in that they check for host_defined_options in the cache now, but this causes a large amount of cache misses and extra memory usage in both chrome and node, so they're still working on it.