You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Maglev on x64 causes segmentation fault while running TypeScript #52797
How often does it reproduce? Is there a required condition?
For this reproduction it’s reproduced consistently on Linux on both my machine and GitHub actions.
While troubleshooting by trimming down the content of node_modules/@types/mdast/index.d.ts, I got into a state where it seemed to happen randomly. The major factor is the 👉 emoji in a comment.
The error did not occur on macOS in the GitHub action, but it did happen consistently for @wooorm on their macbook.
The problem was not reproducible on Windows.
What is the expected behavior? Why is that the expected behavior?
No segmentation fault
What do you see instead?
Segmentation fault (core dumped)
Additional information
This was originally reported to TypeScript: microsoft/TypeScript#58369. This issue contains more information.
This has coincidentally already been fixed for the upcoming TypeScript 5.5. Still, a segfault should not occur.
I would absolutely love to. Unfortunately the bug is reproduced by running tsc. Neither I nor the TypeScript team have been able to make a small reproduction.
AFAICT this doesn't seem like an issue with Node.js itself, but rather a compiler (such as tsc), but I'm no expert, and I'd love to get a second opinion.
It's probably related to V8, but I'm not sure waiting would have changed anything? We released v22.0.0 with the version of V8 that's in current Chrome.
Looking at the related bugs I think we should disable maglev by default for v22, considering it will get stuck with V8 12.4 for ~2 years, and it will probably be increasingly difficult to backport any maglev patches to it even if they get fixed in the upstream. We could continue enabling it on the main branch and maybe consider enabling it in v23 to test it out, but it doesn't look great to ship the crashes to LTS.
Reacted by Matteo Collina, Marco Ippolito, Daryl Haresign, Chengzhong Wu, Christopher Monsanto and Théo LUDWIG
Yup the repro mentioned in this post can be run with ELECTRON_RUN_AS_NODE=1 <electron x64 binary> node_modules/.bin/tsc
Simple bisect of our prebuilt binaries showed, first good version is 128.0.6571.0 and last known bad version is 127.0.6521.0. So I can confirm that it is definitely addressed in V8 12.8 but haven't bisected to which commit addressed it.
I hit this tonight with the following node version:
Resolved package.json as 22.3.0
Attempting to download 22.3.0...
Acquiring 22.3.0 - x64 from https://github.com/actions/node-versions/releases/download/22.3.0-95[69](https://github.com/emberjs/data/actions/runs/15011990197/job/42182302379?pr=9989#step:3:75)309553/node-22.3.0-linux-x64.tar.gz
from this thread, it's not totally clear which minor/patch of 22 got the fix added so if someone has that detail (or that it never did) would be gtk. I resolved by bumping to node 24.
Activity
avivkeller commentedon May 2, 2024
Hi! Could you possibly provide some example code to reproduce this? Preferably code that has been compiled into plain JS.
remcohaszing commentedon May 2, 2024
I would absolutely love to. Unfortunately the bug is reproduced by running
tsc. Neither I nor the TypeScript team have been able to make a small reproduction.It was caused by microsoft/TypeScript#53081 and fixed by microsoft/TypeScript#58339 (unreleased yet).
avivkeller commentedon May 2, 2024
AFAICT this doesn't seem like an issue with Node.js itself, but rather a compiler (such as
tsc), but I'm no expert, and I'd love to get a second opinion.remcohaszing commentedon May 2, 2024
Sorry, I now see I forgot to provide a critical piece of information. This is a regression in Node.js 22.0.0. It wasn’t a problem before.
avivkeller commentedon May 2, 2024
Ahh, okay, thank you.
mcollina commentedon May 2, 2024
@targos I have a feel we rushed the V8 upgrades.
cc @nodejs/v8 @RafaelGSS
targos commentedon May 2, 2024
It's probably related to V8, but I'm not sure waiting would have changed anything? We released v22.0.0 with the version of V8 that's in current Chrome.
targos commentedon May 2, 2024
Seems specific to Linux or x64 as I cannot reproduce on ARM64 macOS.
targos commentedon May 2, 2024
We also don't know which version of V8 introduced the bug (assuming it's in V8).
targos commentedon May 2, 2024
So, it's specific to x64. I can reproduce with
node-v22.0.0-darwin-x64on Rosetta.41 remaining items
targos commentedon Aug 8, 2024
A full V8 update in v22 is very unlikely (too many breaking changes in the C++ API)
joyeecheung commentedon Aug 14, 2024
Looking at the related bugs I think we should disable maglev by default for v22, considering it will get stuck with V8 12.4 for ~2 years, and it will probably be increasingly difficult to backport any maglev patches to it even if they get fixed in the upstream. We could continue enabling it on the main branch and maybe consider enabling it in v23 to test it out, but it doesn't look great to ship the crashes to LTS.
mcollina commentedon Aug 14, 2024
It seems the safest approach, considering that there isn't really much we can do.
src: create handle scope in FastInternalModuleStat
Revert "v8: enable maglev on supported architectures"
targos commentedon Sep 19, 2024
Maglev was disabled on v22.x with #54384
jakebailey commentedon Sep 19, 2024
It's still enabled on main, right? So it's still not fixed until V8 is fixed?
targos commentedon Sep 19, 2024
Do we know that this issue also affects
main?joyeecheung commentedon Sep 19, 2024
BTW on the V8 slack @deepak1556 mentioned that they were able to reproduce it in Electron with v8 12.4 and 12.6 but not 12.8 so it's likely fixed.
deepak1556 commentedon Sep 19, 2024
Yup the repro mentioned in this post can be run with
ELECTRON_RUN_AS_NODE=1 <electron x64 binary> node_modules/.bin/tscSimple bisect of our prebuilt binaries showed, first good version is
128.0.6571.0and last known bad version is127.0.6521.0. So I can confirm that it is definitely addressed in V8 12.8 but haven't bisected to which commit addressed it.Here is the chromium changelist url https://chromium.googlesource.com/chromium/src/+log/127.0.6521.0..128.0.6571.0?n=10000&pretty=fuller and V8 changelist https://chromium.googlesource.com/v8/v8/+log/12.7.189..12.8.185?n=10000&pretty=fuller
runspired commentedon May 14, 2025
I hit this tonight with the following node version:
from this thread, it's not totally clear which minor/patch of 22 got the fix added so if someone has that detail (or that it never did) would be gtk. I resolved by bumping to node 24.
bnoordhuis commentedon May 15, 2025
@runspired