search

vitest-dev / vitest

Next generation testing framework powered by Vite.
https://vitest.dev
MIT License
12.74k stars 1.15k forks source link

Resource Busy Or Locked Error #5740

Open irv075 opened 5 months ago

irv075 commented 5 months ago

Describe the bug

The extension throws a resource busy or locked exception intermittently. It seems to be trying to access files in the root of the C drive - usually c:\DumpStack.log.tmp or c:\hiberfil.sys (if dumpstack logging has been disabled).

After the error has been thrown I have to disable then re-enable the extension to get it running again - it will then fail again after an amount of time ranging from a few seconds to 15 minutes.

OS: Windows 10 VS Code:1.88.1 Vitest Extension: 0.8.6

Reproduction

No special reproduction required, the exception is thrown even when no tests are being ran, just having the extension enabled for a period of time.

Output

[INFO 10:26:05 AM] [v0.8.6] Vitest extension is activated because Vitest is installed or there is a Vite/Vitest config file in the workspace.
[INFO 10:26:06 AM] [API] Running Vitest: v1.5.0 (vitest.config.ts)
[INFO 10:26:06 AM] [API] Starting Vitest process with Node.js: C:\Program Files\nodejs\node.EXE
[INFO 10:26:09 AM] [API] Vitest process 454476 created
[INFO 10:26:29 AM] [API] Vitest process 454476 closed successfully
[INFO 10:26:29 AM] [API] Running Vitest: v1.5.0 (vitest.config.ts)
[INFO 10:26:29 AM] [API] Starting Vitest process with Node.js: C:\Program Files\nodejs\node.EXE
[INFO 10:26:31 AM] [API] Vitest process 521280 created
[Worker] node:events:496
      throw er; // Unhandled 'error' event
      ^

Error: EBUSY: resource busy or locked, lstat 'C:\hiberfil.sys'
Emitted 'error' event on FSWatcher instance at:
    at FSWatcher._handleError (file:///C:/Repositories/testapp/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:46060:10)
    at NodeFsHandler._boundHandleError (file:///C:/Repositories/testapp/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:44533:43)
    at ReaddirpStream.emit (node:events:518:28)
    at emitErrorNT (node:internal/streams/destroy:169:8)
    at emitErrorCloseNT (node:internal/streams/destroy:128:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
  errno: -4082,
  code: 'EBUSY',
  syscall: 'lstat',
  path: 'C:\\hiberfil.sys'
}

Node.js v20.11.0

Version

0.8.6

Validations

hi-ogawa commented 5 months ago

Quick googling is suggesting that this might be because of some plugins not following Vite's convention:

Can you check if you have any plugins which might be doing something similar? Also, can you check if you can reproduce with vitest cli without vscode extension?

irv075 commented 4 months ago

Apologies for the delay in replying.

I am not using any additional plugins for vitest, and only the React plugin for vite. The issue does seem to be reproduced when using vitest cli:


 ✓ src/pages/requests/requests.test.tsx  (16 tests) 939ms

 Test Files  1 passed (1)
      Tests  16 passed (16)
   Start at  12:25:56
   Duration  9.94s

 PASS  Waiting for file changes...
       press h to show help, press q to quit
node:events:496
      throw er; // Unhandled 'error' event
      ^

Error: EBUSY: resource busy or locked, lstat 'C:\hiberfil.sys'
Emitted 'error' event on FSWatcher instance at:
    at FSWatcher._handleError (file:///C:/Repositories/testapp/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:46060:10)
    at NodeFsHandler._boundHandleError (file:///C:/Repositories/testapp/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:44533:43)
    at ReaddirpStream.emit (node:events:518:28)
    at emitErrorNT (node:internal/streams/destroy:169:8)
    at emitErrorCloseNT (node:internal/streams/destroy:128:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
  errno: -4082,
  code: 'EBUSY',
  syscall: 'lstat',
  path: 'C:\\hiberfil.sys'
}

Node.js v20.11.0
hi-ogawa commented 4 months ago

only the React plugin for vite

Interesting. Actually official react plugin is also doing /@react-refresh https://github.com/vitejs/vite-plugin-react/blob/814ed8043d321f4b4679a9f4a781d1ed14f185e4/packages/plugin-react/src/fast-refresh.ts#L5, so that's might be the culprit.

The issue does seem to be reproduced when using vitest cli

Thanks for confirming. For now, I'll move this issue to Vitest repo, but I this it's also possible that the same issue can happen on Vite cli too. If that's the case, we need to report that to either Vite or React plugin https://github.com/vitejs/vite-plugin-react

hi-ogawa commented 4 months ago

Btw, can you provide "System Info" in a comment? You can simply run npx envinfo --system --npmPackages '{vitest,@vitest/*,vite,@vitejs/*}' --binaries --browsers like we have on issue template https://github.com/vitest-dev/vitest/issues/new?assignees=&labels=pending+triage&projects=&template=bug_report.yml

hi-ogawa commented 4 months ago

@patak-dev It looks like the issue of /@react-refresh not following \0 convention is brought up in https://github.com/vitejs/vite/pull/15299. Does Vite team have any plan to change it in the future?

irv075 commented 4 months ago

Btw, can you provide "System Info" in a comment? You can simply run npx envinfo --system --npmPackages '{vitest,@vitest/*,vite,@vitejs/*}' --binaries --browsers like we have on issue template https://github.com/vitest-dev/vitest/issues/new?assignees=&labels=pending+triage&projects=&template=bug_report.yml

System: OS: Windows 10 10.0.19045 CPU: (12) x64 Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz Memory: 15.24 GB / 31.64 GB

Binaries: Node: 20.11.0 - C:\Program Files\nodejs\node.EXE npm: 10.2.4 - C:\Program Files\nodejs\npm.CMD

Browsers: Edge: Chromium (120.0.2210.144) Internet Explorer: 11.0.19041.3636

npmPackages: @vitejs/plugin-react: 4.2.1 => 4.2.1 @vitest/coverage-v8: ^1.5.0 => 1.5.0 @vitest/ui: ^1.5.0 => 1.5.0 vite: ^5.2.10 => 5.2.10 vitest: ^1.5.0 => 1.5.0

nistre commented 2 months ago

Do you have "nx": {} in your root package.json. I started encountering this issue when I added the nx to the root package.json and the error goes away when I:

With my obvious connection to nx, I'm 1.) not sure if it would be nx or a vite at fault and 2.) If it is related to this issue

irv075 commented 2 months ago

Do you have "nx": {} in your root package.json

No, we dont use nx at all in this project.

nistre commented 2 months ago

Gotcha. My issue was caused by creating an infinite loop with my root npm run build was calling itself and I needed to add an appropriate --exclued to the script. Good luck with your issue.