Node.js Version
v22.23.2, official Windows x64 executable; V8 12.4.254.21-node.56; modules ABI 127.
NPM Version
Not used for the failing runs. The pinned node.exe directly ran the locally installed Vitest CLI.
Operating System
Windows x64. Current readout: Microsoft Windows NT 10.0.26200.0. Hardware: Intel Core i5-13600KF, ASUS B760M-T, 32 GiB RAM. Current BIOS is 1812, with Intel Default Settings / Performance and XMP Disabled. These current settings do not establish the settings at the time of earlier failures or rule out a hardware problem.
Subsystem
v8
Description
I am looking for a targeted way to capture the first invalid value before an intermittent V8 fatal on Windows. I do not yet have a deterministic reproduction or evidence assigning the cause to Node/V8, an addon, or the machine.
Two captured failures reached Runtime_LoadIC_Miss from generated JavaScript while running a local test suite. Offline inspection using the matching official PDB and the matching Node source found a difference between the feedback-vector argument supplied to Runtime_LoadIC_Miss and the feedback vector stored in the JavaScript frame:
- Capture A: argument 3 has instance type 195 (FUNCTION_CONTEXT_TYPE), matching the caller context. The frame's feedback-vector object has type 258 (FEEDBACK_VECTOR_TYPE). The receiver also differs from the value saved at the generated call site; name and slot match.
- Capture B: argument 3 has instance type 2066 (JS_FUNCTION_TYPE), matching the caller function. The frame's feedback-vector object still has type 258. The generated call targets LoadICBaseline.
Argument indexing was checked against the exact Runtime_LoadIC_Miss disassembly (argv - index * 8), not inferred from a generic stack scanner. These are post-failure snapshots, not a trace of the earlier writes or execution. I cannot determine whether the divergence already existed at IC entry, arose later, or reflects another problem.
Minimal Reproduction
None established. The observed trigger was a Vitest 4.1.11 test worker running Zod 4.5.4 generated object validation. The environment also has better-sqlite3 12.11.1 and Sharp 0.34.5. Native modules present in a captured process include SQLite, Sharp/libvips and a local fatal-dump callback; addon or instrumentation involvement is not excluded.
The two captured worker lifetimes were approximately six and three seconds, respectively. I have not established a dependence on a long-lived worker or accumulated JS heap state.
Reduced checks have not reproduced the fatal: one million parses of an anonymous schema matching the validation shape; 100,000 iterations of the relevant pure-JS validation/projection path; and 1,000 read-only replays using a copy of the anonymous test database. Standalone runs of the affected test group have also passed. These passing runs are not evidence of a fix. No application data or external services are needed by the isolated checks.
Output
Capture A:
Check failed: static_cast<unsigned>(index) < static_cast<unsigned>(length()).
V8_Fatal
FeedbackMetadata::GetKind
FeedbackVector::GetKind
Runtime_LoadIC_Miss
[generated code; native PE unwind stopped here]
Capture B:
Fatal error: unreachable code
V8_Fatal
FeedbackMetadata::GetSlotSize
FeedbackNexus::GetFeedbackPair
FeedbackNexus::ic_state
IC::IC
Runtime_LoadIC_Miss
[generated code; native PE unwind stopped here]
Checks already performed and their limits
- The captured LoadIC and Runtime_LoadIC_Miss bytes match the pinned executable. For capture B, all 30,713,284 file-backed executable-section bytes of Node were present and matched the disk file. This does not cover generated code, heap/stack state, or earlier writes.
- Captured native module code and the corresponding installed files were compared; the SQLite addon also matched its official ABI-127 prebuild. This does not rule out a defect in otherwise intact native code.
- Existing heap-check and anonymous second-machine checks did not produce the same fatal. Windows memory diagnostics reported no bad pages. None of these observations rules out CPU/RAM/firmware instability.
- I have retained the original failures. I have not disabled JIT, changed assertions, or treated a subsequent passing test run as a root-cause fix.
Specific question
For this exact Node/V8 build on Windows x64, what is the most useful next supported diagnostic to catch the first divergence of the LoadIC feedback-vector argument? In particular, is there a targeted breakpoint, assertion, or bounded trace point that can distinguish an already-invalid IC entry argument from corruption after entry, before attempting another full-suite run?
I can prepare a small anonymous probe based on a recommended diagnostic. This request is for the next discriminating observation, not a claim of a confirmed V8 bug. No raw dumps, project source, database, credentials, local usernames/paths, or user media are attached.
Minimal Reproduction
No response
Output
No response
Before You Submit
Node.js Version
v22.23.2, official Windows x64 executable; V8 12.4.254.21-node.56; modules ABI 127.
NPM Version
Not used for the failing runs. The pinned node.exe directly ran the locally installed Vitest CLI.
Operating System
Windows x64. Current readout: Microsoft Windows NT 10.0.26200.0. Hardware: Intel Core i5-13600KF, ASUS B760M-T, 32 GiB RAM. Current BIOS is 1812, with Intel Default Settings / Performance and XMP Disabled. These current settings do not establish the settings at the time of earlier failures or rule out a hardware problem.
Subsystem
v8
Description
I am looking for a targeted way to capture the first invalid value before an intermittent V8 fatal on Windows. I do not yet have a deterministic reproduction or evidence assigning the cause to Node/V8, an addon, or the machine.
Two captured failures reached Runtime_LoadIC_Miss from generated JavaScript while running a local test suite. Offline inspection using the matching official PDB and the matching Node source found a difference between the feedback-vector argument supplied to Runtime_LoadIC_Miss and the feedback vector stored in the JavaScript frame:
Argument indexing was checked against the exact Runtime_LoadIC_Miss disassembly (argv - index * 8), not inferred from a generic stack scanner. These are post-failure snapshots, not a trace of the earlier writes or execution. I cannot determine whether the divergence already existed at IC entry, arose later, or reflects another problem.
Minimal Reproduction
None established. The observed trigger was a Vitest 4.1.11 test worker running Zod 4.5.4 generated object validation. The environment also has better-sqlite3 12.11.1 and Sharp 0.34.5. Native modules present in a captured process include SQLite, Sharp/libvips and a local fatal-dump callback; addon or instrumentation involvement is not excluded.
The two captured worker lifetimes were approximately six and three seconds, respectively. I have not established a dependence on a long-lived worker or accumulated JS heap state.
Reduced checks have not reproduced the fatal: one million parses of an anonymous schema matching the validation shape; 100,000 iterations of the relevant pure-JS validation/projection path; and 1,000 read-only replays using a copy of the anonymous test database. Standalone runs of the affected test group have also passed. These passing runs are not evidence of a fix. No application data or external services are needed by the isolated checks.
Output
Capture A:
Capture B:
Checks already performed and their limits
Specific question
For this exact Node/V8 build on Windows x64, what is the most useful next supported diagnostic to catch the first divergence of the LoadIC feedback-vector argument? In particular, is there a targeted breakpoint, assertion, or bounded trace point that can distinguish an already-invalid IC entry argument from corruption after entry, before attempting another full-suite run?
I can prepare a small anonymous probe based on a recommended diagnostic. This request is for the next discriminating observation, not a claim of a confirmed V8 bug. No raw dumps, project source, database, credentials, local usernames/paths, or user media are attached.
Minimal Reproduction
No response
Output
No response
Before You Submit