Repository navigation
"Fatal error, unreachable code" seen intermittently on v20.10.0 #51555
Copy link
Copy link
Closed as not planned
Labels
confirmed-bugIssues and PRs for confirmed bugs.Issues and PRs for confirmed bugs.
Description
Version
v20.10.0
Platform
Linux codespaces-110a35 6.2.0-1018-azure #18~22.04.1-Ubuntu SMP Tue Nov 21 19:25:02 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Subsystem
No response
What steps will reproduce the bug?
Sorry, I don't have an easy repro.
How often does it reproduce? Is there a required condition?
I can't repro it reliably, it happens intermittently. In CI, I'm seeing it a few times per day
What is the expected behavior? Why is that the expected behavior?
It shouldn't crash
What do you see instead?
#
# Fatal error in , line 0
# unreachable code
#
#
#
#FailureMessage Object: 0x7fffaf0a2d00
1: 0xd17f41 [node]
2: 0x20fe211 V8_Fatal(char const*, ...) [node]
3: 0x10c1d84 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
4: 0x10c2ef5 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
5: 0x1534cea v8::internal::Heap::AllocateRawOrFail(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
6: 0x1535fb2 v8::internal::Deserializer<v8::internal::Isolate>::Allocate(v8::internal::AllocationType, int, v8::internal::AllocationAlignment) [node]
7: 0x1539589 v8::internal::Deserializer<v8::internal::Isolate>::ReadObject(v8::internal::SnapshotSpace) [node]
8: 0x1539909 int v8::internal::Deserializer<v8::internal::Isolate>::ReadSingleBytecodeData<v8::internal::SlotAccessorForHandle<v8::internal::Isolate> >(unsigned char, v8::internal::SlotAccessorForHandle<v8::internal::Isolate>) [node]
9: 0x153a20f v8::internal::Deserializer<v8::internal::Isolate>::ReadObject() [node]
10: 0x1539556 v8::internal::Deserializer<v8::internal::Isolate>::ReadObject(v8::internal::SnapshotSpace) [node]
11: 0x153822b int v8::internal::Deserializer<v8::internal::Isolate>::ReadSingleBytecodeData<v8::internal::SlotAccessorForHeapObject>(unsigned char, v8::internal::SlotAccessorForHeapObject) [node]
12: 0x1539361 v8::internal::Deserializer<v8::internal::Isolate>::ReadData(v8::internal::Handle<v8::internal::HeapObject>, int, int) [node]
13: 0x1539628 v8::internal::Deserializer<v8::internal::Isolate>::ReadObject(v8::internal::SnapshotSpace) [node]
14: 0x153822b int v8::internal::Deserializer<v8::internal::Isolate>::ReadSingleBytecodeData<v8::internal::SlotAccessorForHeapObject>(unsigned char, v8::internal::SlotAccessorForHeapObject) [node]
15: 0x1539361 v8::internal::Deserializer<v8::internal::Isolate>::ReadData(v8::internal::Handle<v8::internal::HeapObject>, int, int) [node]
16: 0x1539628 v8::internal::Deserializer<v8::internal::Isolate>::ReadObject(v8::internal::SnapshotSpace) [node]
17: 0x153822b int v8::internal::Deserializer<v8::internal::Isolate>::ReadSingleBytecodeData<v8::internal::SlotAccessorForHeapObject>(unsigned char, v8::internal::SlotAccessorForHeapObject) [node]
18: 0x1539361 v8::internal::Deserializer<v8::internal::Isolate>::ReadData(v8::internal::Handle<v8::internal::HeapObject>, int, int) [node]
19: 0x1539628 v8::internal::Deserializer<v8::internal::Isolate>::ReadObject(v8::internal::SnapshotSpace) [node]
20: 0x153822b int v8::internal::Deserializer<v8::internal::Isolate>::ReadSingleBytecodeData<v8::internal::SlotAccessorForHeapObject>(unsigned char, v8::internal::SlotAccessorForHeapObject) [node]
21: 0x1539361 v8::internal::Deserializer<v8::internal::Isolate>::ReadData(v8::internal::Handle<v8::internal::HeapObject>, int, int) [node]
22: 0x1539628 v8::internal::Deserializer<v8::internal::Isolate>::ReadObject(v8::internal::SnapshotSpace) [node]
23: 0x153822b int v8::internal::Deserializer<v8::internal::Isolate>::ReadSingleBytecodeData<v8::internal::SlotAccessorForHeapObject>(unsigned char, v8::internal::SlotAccessorForHeapObject) [node]
24: 0x1539361 v8::internal::Deserializer<v8::internal::Isolate>::ReadData(v8::internal::Handle<v8::internal::HeapObject>, int, int) [node]
[25](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:26): 0x1539628 v8::internal::Deserializer<v8::internal::Isolate>::ReadObject(v8::internal::SnapshotSpace) [node]
[26](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:27): 0x153822b int v8::internal::Deserializer<v8::internal::Isolate>::ReadSingleBytecodeData<v8::internal::SlotAccessorForHeapObject>(unsigned char, v8::internal::SlotAccessorForHeapObject) [node]
[27](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:28): 0x1539361 v8::internal::Deserializer<v8::internal::Isolate>::ReadData(v8::internal::Handle<v8::internal::HeapObject>, int, int) [node]
[28](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:29): 0x1539628 v8::internal::Deserializer<v8::internal::Isolate>::ReadObject(v8::internal::SnapshotSpace) [node]
[29](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:30): 0x153822b int v8::internal::Deserializer<v8::internal::Isolate>::ReadSingleBytecodeData<v8::internal::SlotAccessorForHeapObject>(unsigned char, v8::internal::SlotAccessorForHeapObject) [node]
[30](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:31): 0x1539361 v8::internal::Deserializer<v8::internal::Isolate>::ReadData(v8::internal::Handle<v8::internal::HeapObject>, int, int) [node]
[31](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:32): 0x1539628 v8::internal::Deserializer<v8::internal::Isolate>::ReadObject(v8::internal::SnapshotSpace) [node]
[32](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:33): 0x153822b int v8::internal::Deserializer<v8::internal::Isolate>::ReadSingleBytecodeData<v8::internal::SlotAccessorForHeapObject>(unsigned char, v8::internal::SlotAccessorForHeapObject) [node]
[33](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:34): 0x1539361 v8::internal::Deserializer<v8::internal::Isolate>::ReadData(v8::internal::Handle<v8::internal::HeapObject>, int, int) [node]
[34](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:35): 0x1539628 v8::internal::Deserializer<v8::internal::Isolate>::ReadObject(v8::internal::SnapshotSpace) [node]
[35](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:36): 0x153822b int v8::internal::Deserializer<v8::internal::Isolate>::ReadSingleBytecodeData<v8::internal::SlotAccessorForHeapObject>(unsigned char, v8::internal::SlotAccessorForHeapObject) [node]
[36](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:37): 0x1539361 v8::internal::Deserializer<v8::internal::Isolate>::ReadData(v8::internal::Handle<v8::internal::HeapObject>, int, int) [node]
[37](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:38): 0x1539628 v8::internal::Deserializer<v8::internal::Isolate>::ReadObject(v8::internal::SnapshotSpace) [node]
[38](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:39): 0x153822b int v8::internal::Deserializer<v8::internal::Isolate>::ReadSingleBytecodeData<v8::internal::SlotAccessorForHeapObject>(unsigned char, v8::internal::SlotAccessorForHeapObject) [node]
[39](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:40): 0x1539361 v8::internal::Deserializer<v8::internal::Isolate>::ReadData(v8::internal::Handle<v8::internal::HeapObject>, int, int) [node]
[40](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:41): 0x1539628 v8::internal::Deserializer<v8::internal::Isolate>::ReadObject(v8::internal::SnapshotSpace) [node]
[41](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:42): 0x153822b int v8::internal::Deserializer<v8::internal::Isolate>::ReadSingleBytecodeData<v8::internal::SlotAccessorForHeapObject>(unsigned char, v8::internal::SlotAccessorForHeapObject) [node]
[42](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:43): 0x1539361 v8::internal::Deserializer<v8::internal::Isolate>::ReadData(v8::internal::Handle<v8::internal::HeapObject>, int, int) [node]
[43](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:44): 0x1539628 v8::internal::Deserializer<v8::internal::Isolate>::ReadObject(v8::internal::SnapshotSpace) [node]
[44](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:45): 0x153822b int v8::internal::Deserializer<v8::internal::Isolate>::ReadSingleBytecodeData<v8::internal::SlotAccessorForHeapObject>(unsigned char, v8::internal::SlotAccessorForHeapObject) [node]
[45](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:46): 0x1539361 v8::internal::Deserializer<v8::internal::Isolate>::ReadData(v8::internal::Handle<v8::internal::HeapObject>, int, int) [node]
[46](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:47): 0x1539628 v8::internal::Deserializer<v8::internal::Isolate>::ReadObject(v8::internal::SnapshotSpace) [node]
[47](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:48): 0x153822b int v8::internal::Deserializer<v8::internal::Isolate>::ReadSingleBytecodeData<v8::internal::SlotAccessorForHeapObject>(unsigned char, v8::internal::SlotAccessorForHeapObject) [node]
[48](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:49): 0x1539361 v8::internal::Deserializer<v8::internal::Isolate>::ReadData(v8::internal::Handle<v8::internal::HeapObject>, int, int) [node]
[49](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:50): 0x1539628 v8::internal::Deserializer<v8::internal::Isolate>::ReadObject(v8::internal::SnapshotSpace) [node]
[50](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:51): 0x1539909 int v8::internal::Deserializer<v8::internal::Isolate>::ReadSingleBytecodeData<v8::internal::SlotAccessorForHandle<v8::internal::Isolate> >(unsigned char, v8::internal::SlotAccessorForHandle<v8::internal::Isolate>) [node]
[51](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:52): 0x153a20f v8::internal::Deserializer<v8::internal::Isolate>::ReadObject() [node]
[52](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:53): 0x1[53](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:54)eda2 v8::internal::ObjectDeserializer::Deserialize() [node]
53: 0x153efb4 v8::internal::ObjectDeserializer::DeserializeSharedFunctionInfo(v8::internal::Isolate*, v8::internal::SerializedCodeData const*, v8::internal::Handle<v8::internal::String>) [node]
[54](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:55): 0x1531cf2 v8::internal::CodeSerializer::Deserialize(v8::internal::Isolate*, v8::internal::AlignedCachedData*, v8::internal::Handle<v8::internal::String>, v8::ScriptOriginOptions, v8::internal::MaybeHandle<v8::internal::Script>) [node]
[55](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:56): 0xf8bd6b [node]
[56](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:57): 0xf8c04d v8::internal::Compiler::GetSharedFunctionInfoForScriptWithCachedData(v8::internal::Isolate*, v8::internal::Handle<v8::internal::String>, v8::internal::ScriptDetails const&, v8::internal::AlignedCachedData*, v8::ScriptCompiler::CompileOptions, v8::ScriptCompiler::NoCacheReason, v8::internal::NativesFlag) [node]
[57](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:58): 0xeebdcc [node]
[58](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:59): 0xeebed8 v8::ScriptCompiler::CompileUnboundScript(v8::Isolate*, v8::ScriptCompiler::Source*, v8::ScriptCompiler::CompileOptions, v8::ScriptCompiler::NoCacheReason) [node]
[59](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:60): 0xc8c3fe node::contextify::ContextifyScript::New(v8::FunctionCallbackInfo<v8::Value> const&) [node]
[60](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:61): 0xf29f4f v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo) [node]
[61](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:62): 0xf2a505 [node]
[62](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:63): 0xf2ac23 v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) [node]
[63](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:64): 0x1[93](https://github.com/VantaInc/obsidian/actions/runs/7187223522/job/19574346489#step:5:94)4df6 [node]
Trace/breakpoint trap (core dumped)
### Additional information
I'm running node using `ts-node`.
It's being called from a Makefile and several `ts-node` invocations are happening in parallel.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
confirmed-bugIssues and PRs for confirmed bugs.Issues and PRs for confirmed bugs.
Activity
anonrig commentedon Jan 24, 2024
We are seeing similar issues with Node.js 20 on Sentry javascript sdk repository. I couldn't find a repro as well. @joyeecheung Any suggestions?
joyeecheung commentedon Jan 24, 2024
Without a repro it's hard to tell what's going on here. From the stack trace it could be a V8 bug.
joyeecheung commentedon Jan 24, 2024
By the way if a core dump is available that would make it easier to get to clues about what was happening.
chuzarski commentedon Mar 1, 2024
Hello!
I'm currently facing what seems to be the same issue in CI. This occurs on Node 20 (specifically, 20.8.0, 20.10.0, 20.11.0). Our build workers run on Amazon Linux 2023 and we build with 4 parallel processes with Nx.
I did retireve core dumps of these crashes, unfortunately I'm unable to provide them, but I can provide the stack traces from gdb.
This crash:
Has the following stack trace in gdb:
And this crash:
With the following stack trace in gdb:
Ocassionally the following error will occur as well:
However I have been unable to collect a core dump of this error occuring.
Interestingly, these errors typically coincide with Nx printing:
NX Command failed: pnpm --version. Not sure how that could correlate.Hopefully this can help with this issue.
Thanks!
joyeecheung commentedon Mar 2, 2024
IIUC this and OP were both running into issues in a similar setup in actions/setup-node#887 (with GitHub actions)?
From the OP of that issue, I suspect the caching GitHub does could interact poorly with a user land dependency that makes use of vm.Script. It can also be possible that this dependency is monkey patching the builtin CJS loader to compile data with code cache, and for some reason, the cache it uses is mismatching the version of Node.js in the CI, which is why in the other issue, OP reports that they were seeing wrong Node.js versions. AFAIK, one such popular package that does this is https://www.npmjs.com/package/v8-compile-cache - does this package show up in your dependency? If it does, does setting DISABLE_V8_COMPILE_CACHE=1 make the crash go away?
joyeecheung commentedon Mar 2, 2024
Also, I am not sure if it still works on v20, but can you try using LLDB and https://github.com/nodejs/llnode to see if you can print the JS stack trace (the command is "v8 bt" with the plugin) from the core dump? The stack traces indicates that this crash comes from user land JS code, so that would help us pinpoint what JS code (likely a third party package) is causing the crash.
joyeecheung commentedon Mar 2, 2024
From some quick search, it seems pnpm is using v8-compile-cache: https://github.com/search?q=repo%3Apnpm%2Fpnpm%20v8-compile-cache&type=code
And yarn seems to use that too, though I am not able to find where the code is: yarnpkg/berry#5987
I noticed that v8-compile-cache only invalidates the cache when the content of the file changes and doesn't seem to do anything if the V8 version/Node.js version mismatches with the cache. That could be a source of bug like this. If
DISABLE_V8_COMPILE_CACHE =1makes the crash go away, then the crash would be introduced by this package.chuzarski commentedon Mar 3, 2024
Thank you for investigating this!
I'm running into the same issue, but not with Github actions. I'm running into this issue with an Atlasssian Bamboo elastic build agent. This is occurring on a standard AWS EC2 instance, running Amazon Linux. Additionally, I've tested multiple Node 20 versions. Interestingly, this crash does not seem to occur on Windows. We have a project within the same monorepo that is built on Windows. As a result, pnpm and Nx are used there as well.
I'll give this a try and report back
I will also give this a try and report back!
Thank you!
chuzarski commentedon Mar 4, 2024
I set
DISABLE_V8_COMPILE_CACHE=1and I can confirm it seems to prevent these crashes for me. I have had 10/10 successful builds without any nodejs crashes. Before I was experiencing about a 3/10 success rate.Also, it appears llnode still works with Node 20 :D. It also seems
lldbprints a vastly different stack trace, compared to gdb.core dump 1 has the follow stack trace:
core dump 2 has the following stack trace:
It looks like the last JS function is
_moduleCompileinv8-compile-cache(https://github.com/zertosh/v8-compile-cache/blob/v2.3.0/v8-compile-cache.js#L200)I inspected the two parameters for this function:
<String: "/home/bamboo/bamboo-agent-home/xml-data/build-dir/MFGX-MFGXPRPLAN7-JOB1/node_modules/.pnpm/pnpm@8.9.0/node_modules/pnpm/dist/pnpm.cjs">value-0x3ce2fe141149_moduleCompile~content.txt
For both core dumps, the values of these variables are the same. Let me know if anything else is required.
Thanks!
rmlevangelio commentedon Mar 26, 2024
We tried setting
DISABLE_V8_COMPILE_CACHE =1in our yaml files and it still crashing the builds.zxkane commentedon May 22, 2024
It works as workaround in my project. The use case is that the project has lots of AWS Lambda functions written in TS; the intermittent crash happened when parallelly using
esbuildto bundle those functions in jest tests.Add DISABLE_V8_COMPILE_CACHE flag to fix build failure
bradzacher commentedon Jul 23, 2024
We've started to see this crash in our CI agents at Canva.
We recently switched to a setup for our ESLint runs where we run ~30 node instances in parallel and we've started intermittently seeing the following crash occur (which is similar to the one listed in the above comment)
It's worth noting that this is the first time we've seen this crash - we run node across most of our CI and we don't see such crashes elsewhere - it's just been since we switched to hyper-parallelising on one machine.
Note:
v20.12.2v8-compile-cache(it was removed in v8.23.0 -- feat: Enable eslint.config.js lookup from CLI eslint/eslint#16235)v8-compile-cacheI'm still investigating to try and repro or refine the cause - but just posting because it does seem related.
anonrig commentedon Jul 23, 2024
I suspect node::contextify::ContextifyScript might be the root cause of this
10 remaining items
joyeecheung commentedon Sep 24, 2024
The message indicates an
UNREACHABLE()assertion is reached within V8, this is likely to be a unrelated bugs (there are around 4000+UNREACHABLE()assertions in V8 added for various different reasons, each of them can produce this message when hit). In this case you might have been hitting this assertionnode/deps/v8/src/objects/objects.cc
Line 1237 in 5ab3140
Brooooooklyn commentedon Oct 13, 2024
I also encountered this issue frequently in NAPI-RS unit tests recently, as shown in this example: https://github.com/napi-rs/napi-rs/actions/runs/11315439974/job/31466666494?pr=2304
It only shows on
node:20-slimenv (we have 20+ different envs).And the output information suggests it might happen in this test case: https://github.com/napi-rs/napi-rs/blob/napi%403.0.0-alpha.13/examples/napi/tests/worker-thread.spec.ts#L51. This test case creates 100 small buffers in
worker_threadswithin a loop, and terminates them after the buffers are created. There might be race conditions while destroying theworker_threads.chore: Remove flaky crash on CI build
chore: Remove flaky crash on CI build
lb-pendula commentedon Jan 3, 2025
Seeing this exact same issue in 22.11.0. Haven't tried 22.12.0 yet.
joyeecheung commentedon Feb 12, 2025
It seems people have started conflicting other crashes with this one.
int v8::internal::Deserializer<v8::internal::Isolate>::ReadSingleBytecodeDataDISABLE_V8_COMPILE_CACHE=1environment variable to disable the package. As reported above it makes the crash go away for some people.cachedDataoption and disable it somehow (if you are hard-coding to try locally you can just comment out that option, otherwise you will need to report to whatever dependency that is doing this to either fix their usage of the code cache or provide a way to disable it)int v8::internal::Deserializer<v8::internal::Isolate>::ReadSingleBytecodeDatain your stack trace but other kinds of unreachable error, as mentioned there are around 4000+ different unreachable errors that can come from V8 and you are just seeing another unrelated one. Please open a different issue, ideally with a minimal reproduction.Closing as the original issue has a workaround in the third party package.
heath-freenome commentedon May 30, 2025
Seeing the similar issue in my CI pipelines intermittently while running vitest:
[turbopack] Try to fix v8 crashes on github actions (#85114)
fix(ci): implement sequential publishing to prevent V8 cache race con…
fix(ci): prevent V8 cache race conditions + auto-update PRs (#196)
ci: disable v8-compile-cache to fix intermittent V8 deserializer crashes
ci: disable v8-compile-cache to fix intermittent V8 deserializer crashes
Disabled v8-compile-cache to fix intermittent V8 deserializer crashes (…
alumni commentedon Sep 4, 2026
I'm seeing something similar in CI with
node:24.18.0-trixie-slimwhen running tests withjest@30.4.2: