Hitting Segmentation fault when running Vitest .

[Christopher-Stevers]

Describe the bug

When I run vitest on without limiting the threads, the process will crash half way through with the following output:

Segmentation fault (core dumped)
error Command failed with exit code 139.

Reproduction

https://github.com/OpenQDev/OpenQ-Frontend/tree/vite-staging
I can't really provide a minimal reproduction because it seems to depend on the number of tests you run. To reproduce it with this repo just run yarn then, run yarn json-server in one terminal and then yarn vitest in another.

System Info

System:
    OS: Linux 5.4 Ubuntu 20.04.5 LTS (Focal Fossa)
    CPU: (16) x64 Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz
    Memory: 26.75 GB / 31.36 GB
    Container: Yes
    Shell: 5.0.17 - /bin/bash
  Binaries:
    Node: 19.7.0 - ~/nvm/current/bin/node
    Yarn: 1.22.19 - /usr/bin/yarn
    npm: 9.5.0 - ~/nvm/current/bin/npm
  npmPackages:
    @vitejs/plugin-react: ^3.1.0 => 3.1.0 
    vitest: ^0.29.8 => 0.29.8

Used Package Manager

yarn

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[rushil23]

Facing the same here. Really blocking our build flows.

In our case we're facing this issue when running the tests on a github action

[Christopher-Stevers]

My work around at the moment has been to run it with the --no-threads flag when in circleci, but that slows down the workflow a lot.
Locally it works if for us if we are just testing a portion of the code base as long as we limit the threads to 1 or 2.

[nakleiderer]

Potentially similar root cause/duplicate of #3106

Do you have a promise that sometimes rejects in your tests, similar to the reproduction on the linked issue?

EDIT: Fix link to other issue

[adrianisk]

We're potentially hitting this in Github Actions as well, works fine locally though... @nakleiderer did you mean to link to a different issue?

[nakleiderer]

@adrianisk Yes, apologies, I've updated the original comment. This is the link I meant to use: #3106

[mortkarlberg]

We have the same issue. Works fine locally, but in CI on GitHub Actions we have to run sequentially with the --no-threads flag.

[adrianisk]

We're also hitting this issue which happened when we introduced an @AWS-SDK dependency. I happened to stumble upon awslabs/aws-crt-nodejs#452 while looking into something else, might be related?

[emouragym]

Pretty much the same thing is happening, update to AWS-SDK v3 imports, and now we are getting segfaults on GithubActions.

[berenddeboer]

Same here.

[berenddeboer]

Can also be fixed by setting threads in vite.config.ts to false, until a better solution is found.

[AriPerkkio]

Instead of disabling threads option completely, you could also move only the @aws-sdk related test cases to node:child_process. This way all other tests are running in node:worker_threads fast as usual, and the ones that are not compatible with node:worker_threads are run in node:child_process.

Use the poolMatchGlobs option:

import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    poolMatchGlobs: [
      // Run AWS tests in child_process - @aws-sdk crashes when run in 'node:worker_threads'
      ['**/tests/aws-infra-etc-pattern/**', 'child_process'],
    ]
  }
})

[berenddeboer]

On repeatability, I can repeat this in a docker container with just 1 test.And indeed using @AWS-SDK.

[AriPerkkio]

Fixed by #3925 and #4172.

Vitest 1.0.0-beta has now --pool=forks which uses multiple node:child_process in parallel. The previous --no-threads was using a single node:child_process.

If the code you are testing is incompatible with node:worker_threads, switch to --pool=forks. If you run into same error with that pool, feel free to open new issue with minimal reproduction.