Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Segfault while executing w/ vitest + volta
See original GitHub issue🐛 Bug Report
When running fast-check I got this crash:
#
# Fatal error in , line 0
# Check failed: result.second.
#
#
#
#FailureMessage Object: 0x1731b93a8
1: 0x10236fff4 node::NodePlatform::GetStackTracePrinter()::$_3::__invoke() [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
2: 0x103111dd0 V8_Fatal(char const*, ...) [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
3: 0x1026f6684 v8::internal::GlobalBackingStoreRegistry::Register(std::__1::shared_ptr<v8::internal::BackingStore>) [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
4: 0x102472dbc v8::ArrayBuffer::GetBackingStore() [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
5: 0x1022ef9bc node::Buffer::Data(v8::Local<v8::Value>) [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
6: 0x1023191b0 node::fs::Read(v8::FunctionCallbackInfo<v8::Value> const&) [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
7: 0x1024ccea8 v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo) [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
8: 0x1024cc9a0 v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
9: 0x1024cc22c v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
10: 0x102c0cd0c Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
11: 0xa30089b08
12: 0x102bcfe54 Builtins_AsyncFunctionAwaitResolveClosure [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
13: 0x102c54cf8 Builtins_PromiseFulfillReactionJob [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
14: 0x102bc2234 Builtins_RunMicrotasks [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
15: 0x102b9e524 Builtins_JSRunMicrotasksEntry [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
16: 0x10256fe5c v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
17: 0x102570290 v8::internal::(anonymous namespace)::InvokeWithTryCatch(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
18: 0x10257037c v8::internal::Execution::TryRunMicrotasks(v8::internal::Isolate*, v8::internal::MicrotaskQueue*, v8::internal::MaybeHandle<v8::internal::Object>*) [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
19: 0x102592fb8 v8::internal::MicrotaskQueue::RunMicrotasks(v8::internal::Isolate*) [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
20: 0x10259384c v8::internal::MicrotaskQueue::PerformCheckpoint(v8::Isolate*) [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
21: 0x10225ddb4 node::InternalCallbackScope::Close() [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
22: 0x10225d7c4 node::InternalCallbackScope::~InternalCallbackScope() [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
23: 0x10230c980 node::fs::FSReqPromise<node::AliasedBufferBase<double, v8::Float64Array, void> >::Resolve(v8::Local<v8::Value>) [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
24: 0x102315194 node::fs::AfterStat(uv_fs_s*) [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
25: 0x102b7ebd4 uv__work_done [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
26: 0x102b82370 uv__async_io [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
27: 0x102b940e8 uv__io_poll [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
28: 0x102b82800 uv_run [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
29: 0x10225eccc node::SpinEventLoop(node::Environment*) [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
30: 0x1023a2df4 node::worker::Worker::Run() [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
31: 0x1023a601c node::worker::Worker::StartThread(v8::FunctionCallbackInfo<v8::Value> const&)::$_3::__invoke(void*) [/Users/calebjasik-defined/.volta/tools/image/node/16.16.0/bin/node]
32: 0x1ac55c26c _pthread_start [/usr/lib/system/libsystem_pthread.dylib]
33: 0x1ac55708c thread_start [/usr/lib/system/libsystem_pthread.dylib]
Segmentfault Error Detected
Check failed: result.second.
Refer to https://github.com/nodejs/node/issues/43617
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.
webclient on main [$!?⇣] via v16.16.0 took 5s
❯
To Reproduce
Steps to reproduce:
Expected behavior
Clear and concise description of what you expected to happen.
I expected my tests to run, instead the v8 vm crashed. I’ve seen this happen quite a few times while running with this on my m1 mac
If you have one, please provide a minimal repository reproducing the issue on GitHub.
Your environment
| Packages / Softwares | Version(s) |
|---|---|
| fast-check | “version”: “2.25.0”, |
| node | “node”: “16.16.0”, |
| TypeScript* | “typescript”: “4.7.X”, |
*Only for TypeScript’s users
Issue Analytics
- State:
- Created a year ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
Segmentation fault (core dumped) · Issue #317 · vitest-dev ...
I ran vitest and got: Segmentation fault (core dumped) error Command ... It's always happening locally when running Vitest with --coverage ...
Read more >Identify what's causing segmentation faults (segfaults)
A segmentation fault (aka segfault) is a common condition that causes programs to crash; they are often associated with a file named core...
Read more >Segmentation fault while running Google test
I had a similar issue - segmentation fault on instantiation of mock classes. I build gmock and gtest as static libraries.
Read more >Debugging Segmentation Faults using GEF and GDB
For the sample code, just type "run" and hit enter at the GDB prompt: gef➤ run. Your program should halt when the segmentation...
Read more >Segmentation Fault when running commands
Resolution. In this case, it was caused as the part of glibc was updated while part of is failed; Reinstalling glibc in rescue...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Closing the issue as I cannot reproduce nor do anything based on the details I got in the issue, sorry. Not even sure the problem is on fast-check side without any running code, snippet, codesandbox…
fair, sorry for the lack of useful info.
i’m suspect of fast-check being involved because it always seems to crash while a fast-check property test is running