-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Segfaults #2347
Comments
Experiencing the same. Do you by any chance use TRPC? This is the line it segfaults on:
I also have AWS SDKs and Prisma, so couldn't pinpoint it better yet. |
I'm not using TRPC |
I do not get the error if I use <=0.24.3 but if I use any newer version it segfaults. Presumably the problem was introduced in 0.24.4 |
I have a reproduction: https://github.com/jetbridge/sst-prisma/tree/vitest-segfault - branch Instructions:
As mentioned above, it does not segfault for vitest <=0.24.3 As an aside, if you do downgrade vitest and run the test, it will fail, not segfault, but the exit code will be 0 even though the test failed (ref #2363) |
I've got a reproduction as well (vitest version 0.26.2): themerdev/themer at commit Instructions:
Sometimes it will pass without error. Other times, you'll see something like this:
I've tried using the segfault-handler package to get a better stack trace, but haven't had any luck no matter where I place the handler—perhaps it's happening after the node process executing the test code has already completed or something. |
Still getting a segfault after running all tests on linux, using vitest 0.27.1
|
I too am getting segfaults when running a test file that involves the aws-sdk and only on Linux with node 16 and 18. Interestingly, this issue only manifested for me recently in a GitHub action run (with Edit: Looks like they were failing silently like others described. Looks like the tests run just fine, I get all my tests passing and I put an I also tried using the segfault handler several times at the top of the file, but nothing triggers it to run, so I don't have (nor do I know how) to gather any useful logs for this issue. All of my other tests that don't involve aws-sdk pass without crashing vitest. |
I just upgraded to 0.29.2, and I don't experience the problem anymore |
|
Still happening for me on 0.29.2, Ubuntu running node18. I get this when i run some heavy test packs (with their own idiosyncratic setups) in quick succession to one another e.g.
This is with threads enabled. SingleThread mode is a bit of a no-go for me due to the requirement for separation. Stacktrace:
|
Our issue with segfault was resolved, when we upgraded node from 14 to 18 |
I was having the same issue, but was able to get around it by mocking out any modules that referenced AWS SDK modules, for example: beforeAll(() => {
// Mocking this out is required to prevent segfaults which are likely
// coming from the AWS SDK.
vi.mock("../path/to/aws-module", () => {
return {};
});
}); I guessed the AWS SDKs were causing the issue because it was segfaulting after that test suite (which was importing AWS modules indirectly) was the last logged when running in tests in GH actions on |
Same issue here. Node 16/18 and also using AWS sdk v3 |
Vitest 0.29.x with node 18 is working okay for me now |
Vitest 0.29.x still gives me segfaults with aws-sdk. When enabling |
Having the same problem with |
Having the same problem with As per @mclean25's suggestion, I mocked the |
We're also hitting this issue which happened when we introduced an |
Describe the bug
Vitest runs fine for me but once all my tests pass and it's done running, it segfaults.
It does not segfault for simple tests, but for more complex tests in my application, it segfaults. I suspect aws-sdk and/or prisma libraries. Segfaults definitely happen with prisma tests on linux. On macOS there is a stack trace which points at aws-crt-node. These might be unrelated segfaults, I don't know. Upgrading to latest aws-sdk libs didn't help (this helped a previous time I had segfaults #1488)
Setting
threads: false
in vite.config.ts makes no difference whatsoever as far as I'm able to observeReproduction
I don't have an easy reproduction right now, I will see if it's possible to make one. In the meantime I have two stack traces.
Linux (running under lldb)
https://paste.debian.net/1261041/
Mac
System Info
The text was updated successfully, but these errors were encountered: