Repository navigation
segfault when running jest tests in fastify with esm mode #43083
Description
Activity
I can repro. I don't know if any of your dependencies make use of native addons. If they don't, then this is most likely a bug in node or one of its dependencies (e.g., V8).
cc @nodejs/vm
Thank you for looking into it!
I just removed and reinstalled all node_modules and I got no message about building native addons. Then I grepped for node-gyp in the whole repo: it's only used insegfault-handler, which I installed to get a better traceback of the segfault (and segfault also appears withoutsegfault-handler).@dlemperFuchs What does
find node_modules -name \*.nodeprint?$ find node_modules -name \*.node node_modules/segfault-handler/build/Release/obj.target/segfault-handler.node node_modules/segfault-handler/build/Release/segfault-handler.nodePID 201777 received SIGSEGV for address: 0x10 /home/xbc5/projects/foo/node_modules/.pnpm/segfault-handler@1.3.0/node_modules/segfault-handler/build/Release/segfault-handler.node(+0x31d6)[0x7852db1311d6] /lib64/libc.so.6(+0x55350)[0x7852d79d1350] /lib64/libnode.so.93(+0xcbaf65)[0x7852d883ef65] /lib64/libnode.so.93(_ZN2v88internal7Isolate38RunHostImportModuleDynamicallyCallbackENS0_6HandleINS0_6ScriptEEENS2_INS0_6ObjectEEENS0_11MaybeHandleIS5_EE+0xb5)[0x7852d8fb5565] /lib64/libnode.so.93(_ZN2v88internal25Runtime_DynamicImportCallEiPmPNS0_7IsolateE+0xdd)[0x7852d93233cd] /lib64/libnode.so.93(+0xf86c54)[0x7852d8b0ac54]I'm getting a very similar stack trace for Node v16.14.0 + v14, and Jest v27.5.1. I would make it cleaner if I knew how -- I think I am missing some debug symbols. If someone can help?
I get this error intermittently: but it's generally when loading https://github.com/seriousme/fastify-openapi-glue -- which uses ESM. But it's ALWAYS when using Jest. This library loads fine when I run the server outside of tests.
Also, there's no
find ./node_module -name '*.node'files.I am doing some further testing:
Test order matters. Could it be a race condition?
When running unit tests (no ESM) first and service tests (ESM) after in the same session, no crashes occur.
- doing service tests alone causes crashes: ~20 tests; 50% crash;
- doing unit tests does not cause crashes: ~20 test; 100% pass;
- doing unit test + service tests in that order does not cause crashes: ~20 tests; 100% pass;
- unit tests do not use ESM; service tests do;
- test order is a) unit b) service;
Fixed the issue by properly loading ESM, and everything that entails in doing so.
Simply put: I wasn't handling ESM at all. I was simply using a normal import in TypeScript, which transpiles to a CJS require.
I changed my project to handle ESM, and used top-level await on a dynamic import().
This is still obviously a bug because Node should properly handle this and error.
That maybe gives some insight into the problem.
Reacted by Tobias Nießen@xbc5 you fixed it by simply using a dynamic import instead of a "normal" import? Would you mind having a look at my repo and tell me, what I can change to get it working? I tried several changes of the imports and didn't get it working.
As I already invested many hours, my company wants me to switch to a working solution (node-tap in this case), so this bug will not affect me any longer.
Facing a similar problem with Node 18.18.0. A package that dynamically imports some of its dependencies, when used in any of my tested files results in an immediate ImportModuleDynamically segmentation fault.
What's interesting is Node 20+ presents an
Uncaught [TypeError: A dynamic import callback was invoked without --experimental-vm-modules]that Jest DOM manages to catch and report accurately, which means Jest actually has the code in to handle native errors when thrown properly?Reproduction is available here: https://codesandbox.io/p/devbox/kvwncy
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
Version
v16.15.0
Platform
Linux main-deb 5.10.0-0.bpo.11-amd64 #1 SMP Debian 5.10.92-1~bpo10+1 (2022-02-03) x86_64 GNU/Linux
Subsystem
No response
What steps will reproduce the bug?
git clone https://github.com/dlemperFuchs/fastify-jest-esm-segfault cd fastify-jest-esm-segfault npm install NODE_OPTIONS=--experimental-vm-modules npx jestHow often does it reproduce? Is there a required condition?
reproducible every time
What is the expected behavior?
Jest runs tests in the repo
What do you see instead?
Additional information
Sorry, I'm quite unsure if this is a node problem or a jest or fastify problem. I tried several things within about 40 hours but nothing worked and in my opinion a segfault shouldn't happen while JS code gets executed.