Skip to content
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

OOM when running vitest in docker #5709

Closed
nick318 opened this issue May 11, 2024 · 3 comments
Closed

OOM when running vitest in docker #5709

nick318 opened this issue May 11, 2024 · 3 comments

Comments

@nick318
Copy link

nick318 commented May 11, 2024

Describe the bug

When I run vitest in docker, I face an OOM error

Reproduction

I copied the sample vitest project from https://vitest.dev/guide/ (this one: https://stackblitz.com/edit/vitest-dev-vitest-sc5cep?file=README.md&initialPath=__vitest__/), then added simple Dockerfile to run the tests in docker.

I've created a reproducible repo here - https://github.com/nick318/vitest-oom

Run docker build . to reproduce the issue.

As a result, I face with the following:

#9 153.7 <--- Last few GCs --->
#9 153.7
#9 153.7 [19:0x25393ec0]   152030 ms: Scavenge 1943.4 (2078.5) -> 1930.5 (2078.5) MB, 5.59 / 0.00 ms  (average mu = 0.196, current mu = 0.165) task;
#9 153.7 [19:0x25393ec0]   152094 ms: Scavenge 1943.8 (2078.5) -> 1932.1 (2079.3) MB, 13.11 / 0.00 ms  (average mu = 0.196, current mu = 0.165) task;
#9 153.7 [19:0x25393ec0]   152154 ms: Scavenge 1944.3 (2079.3) -> 1933.0 (2080.3) MB, 12.67 / 0.00 ms  (average mu = 0.196, current mu = 0.165) task;
#9 153.7
#9 153.7
#9 153.7 <--- JS stacktrace --->
#9 153.7
#9 153.7 FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
#9 153.7 ----- Native stack trace -----
#9 153.7
#9 153.7  1: 0xb7d2ac node::OOMErrorHandler(char const*, v8::OOMDetails const&) [node (vitest)]
#9 153.7  2: 0xeb1bfc v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node (vitest)]
#9 153.7  3: 0xeb1dcc v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node (vitest)]
#9 153.7  4: 0x10b99cc  [node (vitest)]
..............

System Info

System:
    OS: macOS 14.3
    CPU: (10) arm64 Apple M1 Max
    Memory: 91.00 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.11.1 - ~/.nvm/versions/node/v20.11.1/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 10.2.4 - ~/.nvm/versions/node/v20.11.1/bin/npm
    bun: 1.0.0 - ~/.bun/bin/bun
  Browsers:
    Chrome: 124.0.6367.158
    Edge: 124.0.2478.97
    Safari: 17.3
  npmPackages:
    @vitest/ui: latest => 1.6.0
    vite: latest => 5.2.11
    vitest: latest => 1.6.0


### Used Package Manager

npm

### Validations

- [X] Follow our [Code of Conduct](https://github.com/vitest-dev/vitest/blob/main/CODE_OF_CONDUCT.md)
- [X] Read the [Contributing Guidelines](https://github.com/vitest-dev/vitest/blob/main/CONTRIBUTING.md).
- [X] Read the [docs](https://vitest.dev/guide/).
- [X] Check that there isn't [already an issue](https://github.com/vitest-dev/vitest/issues) that reports the same bug to avoid creating a duplicate.
- [X] Check that this is a concrete bug. For Q&A open a [GitHub Discussion](https://github.com/vitest-dev/vitest/discussions) or join our [Discord Chat Server](https://chat.vitest.dev).
- [X] The provided reproduction is a [minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) of the bug.
@AriPerkkio
Copy link
Member

Does it help if you don't run everything on the root of the file system?

FROM node:20

+WORKDIR /usr/src/app
ENV NODE_ENV=development
...

@nick318
Copy link
Author

nick318 commented May 12, 2024

@AriPerkkio yes, it helps! Thanks a lot.

@AriPerkkio
Copy link
Member

AriPerkkio commented May 13, 2024

My guess is that Vitest starts to look for test cases in the directory that you are running it (see default of test.includes) and reaches out of memory. As you were running Vitest in the root of your whole file system /, it read every single directory there were. Some of those contained so many files it caused an OOM.

@AriPerkkio AriPerkkio closed this as not planned Won't fix, can't repro, duplicate, stale May 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants