search

vitest-dev / vitest

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

Node Error FATAL ERROR: v8::FromJust Maybe value is Nothing, on Windows (local) and CI build (Linux) #1191

Closed oneillsp96 closed 2 years ago

oneillsp96 commented 2 years ago

Describe the bug

Running "npx vitest run" results in a Node error that repro's about half the time. Usually, all the tests are reported as passing before Node spits out this error. The error appears for me locally on Windows 10, but also causes our Linux (Ubuntu) CI build to fail. My viteconfig file is pretty vanilla, the only slightly abnormal thing I'm using is scss additionalData. I am trying my best to get a sandboxed reproduction, but this is for a corporate project so I am unable to share my full repo. I understand that a full sandbox is required for the bug to be addressed, but I am desperate and confused, and am hoping someone might be able to at least point me in the right direction. I love vite and vitest and this is the last thing preventing me from getting my team onto it.

Below is the output I am seeing:

√ src/scenes/App/advanced-reporting/advanced-reporting-list-view/advanced-reporting-list-view.test.tsx (2 tests) 443ms √ src/components/create-quick-topic-report-modal/create-quick-topic-report-modal.test.tsx (5 tests) 949ms √ src/components/workplace-reactions-aggregate-card/workplace-reactions-aggregate-card.test.tsx (10 tests ) 1002ms FATAL ERROR: v8::FromJust Maybe value is Nothing.

Test Files 6 passed (6) Tests 33 passed (33) Time 17.04s (in thread 2.95s, 577.09%)

1: 00007FF60749815F v8::internal::CodeObjectRegistry::~CodeObjectRegistry+114079 2: 00007FF6074254C6 DSA_meth_get_flags+65542 3: 00007FF60742637D node::OnFatalError+301 4: 00007FF607D46415 v8::V8::FromJustIsNothing+53 5: 00007FF6073423FA v8::internal::MicrotaskQueue::microtasks_policy+22170 6: 00007FF60734229D v8::internal::MicrotaskQueue::microtasks_policy+21821 7: 00007FF6072B2BAD v8::internal::OrderedHashTable<v8::internal::OrderedNameDictionary,3>::NextTableOffset +58157 8: 00007FF6072B0623 v8::internal::OrderedHashTable<v8::internal::OrderedNameDictionary,3>::NextTableOffset +48547 9: 00007FF6072B37CD v8::internal::OrderedHashTable<v8::internal::OrderedNameDictionary,3>::NextTableOffset +61261 10: 00007FF6074962E5 v8::internal::CodeObjectRegistry::~CodeObjectRegistry+106277 11: 00007FF60747E899 v8::internal::CodeObjectRegistry::~CodeObjectRegistry+9433 12: 00007FF6074EC4A8 uv_check_init+120 13: 00007FF6074F7168 uv_run+664 14: 00007FF6074C5E05 node::SpinEventLoop+309 15: 00007FF60735DEC0 v8::internal::interpreter::BytecodeLabel::bind+35776 16: 00007FF607359518 v8::internal::interpreter::BytecodeLabel::bind+16920 17: 00007FF6074E766D uv_poll_stop+557 18: 00007FF608300940 v8::internal::compiler::RepresentationChanger::Uint32OverflowOperatorFor+146416 19: 00007FFD49347034 BaseThreadInitThunk+20 20: 00007FFD4A282651 RtlUserThreadStart+33

Reproduction

run "npx vite run" on Windows 10 with the following vite config (changing scss additional data to pull in a scss file of your choosing)

/// import { defineConfig, splitVendorChunkPlugin } from "vite"; import { inspectorServer } from "react-dev-inspector/plugins/vite"; import react from "@vitejs/plugin-react";

export default defineConfig({ test: { globals: true, environment: "jsdom", }, plugins: [ react(), splitVendorChunkPlugin(), ], css: { preprocessorOptions: { scss: { additionalData: @use "sass:math"; @import "scss/_aw-tools-and-vars-complete"; } } }, server: { port: 8080, strictPort: true, }, build: { sourcemap: true, } }

);

System Info

System:
    OS: Windows 10 10.0.19042
    CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
    Memory: 13.13 GB / 31.83 GB
  Binaries:
    Node: 16.14.2 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.4 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 8.5.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 100.0.4896.127
    Edge: Spartan (44.19041.1266.0), Chromium (100.0.1185.50)
    Internet Explorer: 11.0.19041.1202
  npmPackages:
    @vitejs/plugin-react: 1.3.1 => 1.3.1
    vite: 2.9.5 => 2.9.5
    vitest: 0.10.0 => 0.10.0

Used Package Manager

yarn

Validations

sheremet-va commented 2 years ago

Duplicate: https://github.com/vitest-dev/vitest/issues/317

oneillsp96 commented 2 years ago

@sheremet-va hate to be that guy, but is getting this one resolved a priority? Or is it blocked by issues with Node itself?

antfu commented 2 years ago

@oneillsp96 Can you help to verify if v0.12.3 fixes the error? Thanks.

oneillsp96 commented 2 years ago

it's looking good so far! I will run a few more CI builds tomorrow to validate but I think you got it! Thank you so much!

wKovacs64 commented 2 years ago

Still happening on vitest 0.12.6 (Windows 10) for me.

fwouts commented 2 years ago

I'm also seeing this on vitest 0.17.0 (ubuntu-latest on GitHub Actions).

kalvenschraut commented 2 years ago

Seeing this occasionally also, sometimes appears once a test fails. Main issue this is causing my CI to not think the test failed and keeps on with the rest of the stages.

dartess commented 2 years ago

It looks like the problem is not reproduced on Node 18. The LTS version is coming out in the fall, so we decided to just turn off the multi-threaded mode of vitest for now and just wait a bit.

fwouts commented 2 years ago

Here's an example where it happened on Node 18: https://github.com/fwouts/previewjs/runs/7225194827?check_suite_focus=true

dartess commented 2 years ago

@fwouts thanks for the info, it's very sad.

xiel commented 2 years ago

I'm seeing this error FATAL ERROR: v8::FromJust Maybe value is Nothing. also often in Github Actions. And I'm also using turbo, I'm wondering if this encourage the error. But really hard to debug as it is not happening all the time.

CM-IV commented 2 years ago

Node v16.15.0 Vitejs v3.0.0 Vitest v0.18.0

50/50 Getting these unhandled rejection errors both locally and on a WoodpeckerCI server even though my tests are shown to still pass.

✓ src/tests/links.test.tsx (2)
 ✓ src/tests/todos.test.tsx (2)
 ✓ src/tests/nav.test.tsx (1)
 ✓ src/tests/footer.test.tsx (2)

Test Files  4 passed (4)
     Tests  7 passed (7)
      Time  3.44s (in thread 65ms, 5297.18%)
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ Unhandled Rejection ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Error: 
 ❯ post node_modules/.pnpm/vitest@0.18.0_happy-dom@6.0.3/node_modules/vitest/dist/worker.mjs:70:14
 ❯ node_modules/.pnpm/vitest@0.18.0_happy-dom@6.0.3/node_modules/vitest/dist/chunk-vite-node-utils.af8ead96.mjs:9149:11
 ❯ sendCall node_modules/.pnpm/vitest@0.18.0_happy-dom@6.0.3/node_modules/vitest/dist/chunk-vite-node-utils.af8ead96.mjs:9146:16
 ❯ node_modules/.pnpm/vitest@0.18.0_happy-dom@6.0.3/node_modules/vitest/dist/chunk-runtime-rpc.cc6a06a2.mjs:7:55
      5|   return new Proxy(rpc2, {
      6|     get(target, p, handler) {
      7|       const sendCall = Reflect.get(target, p, handler);
       |                                                       ^
      8|       const safeSendCall = (...args) => withSafeTimers(() => sendCall(...args));
      9|       safeSendCall.asEvent = sendCall.asEvent;
 ❯ withSafeTimers node_modules/.pnpm/vitest@0.18.0_happy-dom@6.0.3/node_modules/vitest/dist/chunk-utils-global.1b22c4fd.mjs:472:20
 ❯ Proxy.safeSendCall node_modules/.pnpm/vitest@0.18.0_happy-dom@6.0.3/node_modules/vitest/dist/chunk-runtime-rpc.cc6a06a2.mjs:7:41
 ❯ process.<anonymous> node_modules/.pnpm/vitest@0.18.0_happy-dom@6.0.3/node_modules/vitest/dist/worker.mjs:34:11
 ❯ process.emit node:events:527:28
 ❯ emit node:internal/process/promises:140:20
FATAL ERROR: v8::FromJust Maybe value is Nothing.
13s
94
1: 0xb0a860 node::Abort() [node]
13s
95
2: 0xa1c193 node::FatalError(char const*, char const*) [node]
13s
96
3: 0xcf97aa v8::Utils::ReportApiFailure(char const*, char const*) [node]
13s
97
4: 0xb0e6cd node::fs::FileHandle::CloseReq::Resolve() [node]
13s
98
5: 0xb0e829 [node]
13s
99
6: 0x1560e0d [node]
13s
100
7: 0x15655e6 [node]
13s
101
8: 0x1577d14 [node]
13s
102
9: 0x1565f38 uv_run [node]
13s
103
10: 0xa43dd5 node::SpinEventLoop(node::Environment*) [node]
13s
104
11: 0xbd43e2 node::worker::Worker::Run() [node]
13s
105
12: 0xbd4b78 [node]
13s
106
13: 0x7fdc80ad9fa3 [/lib/x86_64-linux-gnu/libpthread.so.0]
13s
107
14: 0x7fdc80a0aeff clone [/lib/x86_64-linux-gnu/libc.so.6]
13s
108
Aborted (core dumped)
rcoundon commented 2 years ago

I'm seeing this on Mac OS 12.4 too

FATAL ERROR: v8::FromJust Maybe value is Nothing.
 1: 0x1025d42dc node::Abort() [/Users/rosscoundon/.nvm/versions/node/v16.15.0/bin/node]
 2: 0x1025d4464 node::errors::TryCatchScope::~TryCatchScope() [/Users/rosscoundon/.nvm/versions/node/v16.15.0/bin/node]
 3: 0x102725900 v8::V8::FromJustIsNothing() [/Users/rosscoundon/.nvm/versions/node/v16.15.0/bin/node]
 4: 0x1025d727c node::fs::FileHandle::CloseReq::Resolve() [/Users/rosscoundon/.nvm/versions/node/v16.15.0/bin/node]
 5: 0x1025e9f84 node::fs::FileHandle::ClosePromise()::$_0::__invoke(uv_fs_s*) [/Users/rosscoundon/.nvm/versions/node/v16.15.0/bin/node]
 6: 0x102e42794 uv__work_done [/Users/rosscoundon/.nvm/versions/node/v16.15.0/bin/node]
 7: 0x102e45f30 uv__async_io [/Users/rosscoundon/.nvm/versions/node/v16.15.0/bin/node]
 8: 0x102e57ca8 uv__io_poll [/Users/rosscoundon/.nvm/versions/node/v16.15.0/bin/node]
 9: 0x102e463c0 uv_run [/Users/rosscoundon/.nvm/versions/node/v16.15.0/bin/node]
10: 0x102522ccc node::SpinEventLoop(node::Environment*) [/Users/rosscoundon/.nvm/versions/node/v16.15.0/bin/node]
11: 0x1026669e8 node::worker::Worker::Run() [/Users/rosscoundon/.nvm/versions/node/v16.15.0/bin/node]
12: 0x102669c10 node::worker::Worker::StartThread(v8::FunctionCallbackInfo<v8::Value> const&)::$_3::__invoke(void*) [/Users/rosscoundon/.nvm/versions/node/v16.15.0/bin/node]
13: 0x1bb49c26c _pthread_start [/usr/lib/system/libsystem_pthread.dylib]
14: 0x1bb49708c thread_start [/usr/lib/system/libsystem_pthread.dylib]
/var/folders/z6/5b6qwtvj7217ykrsmtcxckn40000gn/T/npx-603f6023.sh: line 1: 41684 Abort trap: 6           vitest run -t 'Marketing handler campaign requests' src/test/unit/handler/marketing/marketingHandler.test.ts

If I run the test again after receiving this error, it will usually run without error on the 2nd or 3rd attempt

mikestopcontinues commented 2 years ago

For me, the issue happens most frequently when I start vitest. It seems how the tests are randomly shuffled affects if I get the error. But even when I get vitest to start, the process inevitably, indeterminately fails with the same error—and not when all the tests are run. Just whenever. I sometimes experience the process to "freeze," not detecting changes. Then only when I press f to rerun does the process fail.

Error Message ``` # # Fatal error in , line 0 # Check failed: result.second. # # # #FailureMessage Object: 0x70001412ecb0 1: 0x1010c8ef2 node::NodePlatform::GetStackTracePrinter()::$_3::__invoke() [/Users/msc/Library/Application Support/fnm/node-versions/v16.15.1/installation/bin/node] 2: 0x10209ef13 V8_Fatal(char const*, ...) [/Users/msc/Library/Application Support/fnm/node-versions/v16.15.1/installation/bin/node] 3: 0x1014b78de v8::internal::GlobalBackingStoreRegistry::Register(std::__1::shared_ptr) [/Users/msc/Library/Application Support/fnm/node-versions/v16.15.1/installation/bin/node] 4: 0x1011ee0c6 v8::ArrayBuffer::GetBackingStore() [/Users/msc/Library/Application Support/fnm/node-versions/v16.15.1/installation/bin/node] 5: 0x101033fcb node::Buffer::Data(v8::Local) [/Users/msc/Library/Application Support/fnm/node-versions/v16.15.1/installation/bin/node] 6: 0x1010629db node::fs::Read(v8::FunctionCallbackInfo const&) [/Users/msc/Library/Application Support/fnm/node-versions/v16.15.1/installation/bin/node] 7: 0x101244399 v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo) [/Users/msc/Library/Application Support/fnm/node-versions/v16.15.1/installation/bin/node] 8: 0x101243e66 v8::internal::MaybeHandle v8::internal::(anonymous namespace)::HandleApiCallHelper(v8::internal::Isolate*, v8::internal::Handle, v8::internal::Handle, v8::internal::Handle, v8::internal::Handle, v8::internal::BuiltinArguments) [/Users/msc/Library/Application Support/fnm/node-versions/v16.15.1/installation/bin/node] 9: 0x1012435df v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) [/Users/msc/Library/Application Support/fnm/node-versions/v16.15.1/installation/bin/node] 10: 0x101ab6ad9 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit [/Users/msc/Library/Application Support/fnm/node-versions/v16.15.1/installation/bin/node] 11: 0xb528956a3 12: 0xb52895859 13: 0xb5289652d ```
Ram4GB commented 2 years ago

For me, the issue happens most frequently when I start vitest. It seems how the tests are randomly shuffled affects if I get the error. But even when I get vitest to start, the process inevitably, indeterminately fails with the same error—and not when all the tests are run. Just whenever. I sometimes experience the process to "freeze," not detecting changes. Then only when I press f to rerun does the process fail.

Error Message

I see your issue look like me. Please check if you see this is the same. https://github.com/nodejs/node/issues/43617

metonym commented 2 years ago

Per https://github.com/nodejs/node/issues/43617#issuecomment-1170545990, using Node 18 in my GitHub workflow resolved the issue.

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
+     - uses: actions/setup-node@v3
+       with:
+         node-version: 18
Ram4GB commented 2 years ago

Per nodejs/node#43617 (comment), using Node 18 in my GitHub workflow resolved the issue.

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
+     - uses: actions/setup-node@v3
+       with:
+         node-version: 18

Yes, currently solution is using another version of NodeJS. Hope this soon will be fixed in v16

sheremet-va commented 2 years ago

The fix is listed in v16.17.0 proposal, scheduled for August 16th.

The fix for v14 was already backported, and available on staging. Probably will be publically available with the next security release.

NMinhNguyen commented 2 years ago

@sheremet-va out of curiosity, which entry in the changelog is this fix exactly?

sheremet-va commented 2 years ago

@sheremet-va out of curiosity, which entry in the changelog is this fix exactly?

Under “Semver-patch commits”:

sheremet-va commented 2 years ago

In the meantime I've noticed that error happens almost every time if I change teardownTimeout to a small number (like 10). Please, try increasing this number (currently, default is 1000).

OmgImAlexis commented 2 years ago

I noticed a lot of people in here are using node 18 as a work around. Any ideas for myself who's hitting this in node 18?

Adding VITEST_SEGFAULT_RETRY=3 did allow the tests to pass after the 2nd or 3rd time.

FATAL ERROR: v8::FromJust Maybe value is Nothing.
 1: 00007FF6C39394EF node_api_throw_syntax_error+174703
 2: 00007FF6C38C79C6 v8::internal::wasm::WasmCode::safepoint_table_offset+67350
 3: 00007FF6C38C889D node::OnFatalError+301
 4: 00007FF6C4345335 v8::api_internal::FromJustIsNothing+53
 5: 00007FF6C38B02A2 v8::base::CPU::has_fpu+37538
 6: 00007FF6C399B297 uv_timer_stop+1207
 7: 00007FF6C399783B uv_async_send+331
 8: 00007FF6C3996FCC uv_loop_init+1292
 9: 00007FF6C399716A uv_run+202
10: 00007FF6C3966065 node::SpinEventLoop+309
11: 00007FF6C37FD200 v8::internal::wasm::SignatureMap::Freeze+36000
12: 00007FF6C37F8918 v8::internal::wasm::SignatureMap::Freeze+17336
13: 00007FF6C398783D uv_poll_stop+557
14: 00007FF6C4940D70 v8::internal::compiler::ToString+145936
15: 00007FF88D59458D BaseThreadInitThunk+29
16: 00007FF88ECB7558 RtlUserThreadStart+40

 Segmentfault Error Detected 
  FATAL ERROR: v8::FromJust Maybe value is Nothing.
  Refer to https://github.com/vitest-dev/vitest/issues/1191

It seems to be an upstream bug of Node.js. To improve the test stability,
you could pass --segfault-retry=3 or set env VITEST_SEGFAULT_RETRY=3 to
have Vitest auto retries on flaky segfaults.
sheremet-va commented 2 years ago

@OmgImAlexis from stack trace it doesn't seem like your issue is related to what is discussed here (I can see it refers to wasm, but we do not use it ourselves)

We've noticed significant improvements after updating to 16.17, so closing this issue. If you still have any similar errors, please open a new issue.