microsoft
Intermittent crash with --incremental
Stack trace
https://gist.github.com/tmm1/03a124c5e5c19dede914bf6566755a2c
Steps to reproduce
- run
tsgo --noEmit --extendedDiagnostics -p src --incrementalon large project at high frequency in CI
My team is seeing this one too; it also happens intermittently after lots of runs locally.
Version: 7.0.0-dev.20250808.1
Example:
runtime: goroutine stack exceeds 1000000000-byte limit
runtime: sp=0x140d55aa390 stack=[0x140d55aa000, 0x140f55aa000]
fatal error: stack overflow
runtime stack:
runtime.throw({0x104a55ec1?, 0x0?})
runtime/panic.go:1101 +0x38 fp=0x16cbaed90 sp=0x16cbaed60 pc=0x104553cf8
runtime.newstack()
runtime/stack.go:1107 +0x45c fp=0x16cbaeed0 sp=0x16cbaed90 pc=0x10453b55c
runtime.morestack()
runtime/asm_arm64.s:342 +0x70 fp=0x16cbaeed0 sp=0x16cbaeed0 pc=0x104559c80
Our current workaround has been to remove the incremental build cache file: tsconfig.tsbuildinfo. Otherwise, the stack overflow errors will persist once they start happening.
It seems unlikely that we're going to be able to guess at the problem without a repro; if someone comes up with one that would be helpful.
Do you have a test repo you use with a high number of files? We can't give you our production product.
If you're interested one of us could probably pair on a call with you so you can see the error in action.
on our work repo with the current latest tsgo i am able to use the command -b -w to work, but after rebasing my work on master, it hits this stack overflow too. if i have some time i might be able to try reducing what happened in the diff. the crash happens every time for what it's worth, also in a recursive handleDtsMayChangeOfFileAndExportsOfFile (5297963+ frames).
for my remembrance: 5baa0355 -> 2fb30379 is the rebase that caused it.
I have started running into this issue as well after we fully switched to using tsgo yesterday. I seem to be getting it pretty consistently in a specific branch of our repository, but not on develop / others.
Setting incremental to false does fix it, but takes our typechecking time from ~30 seconds to ~100 seconds; definitely not ideal.
It is a private repo, but @jakebailey you should still have access to it from helping us out with other tsgo issues in the past.
Reproduction steps:
git clone [email protected]:marvia/mrb-monorepo.git
cd mrb-monorepo
git switch -c feature/exceljs --track origin/feature/exceljs
npm login
pnpm install
pnpm --filter orderpicker codegen
pnpm typecheck
After some more playing around with it, it seems that installing a different version of @typescript/native-preview "fixes" it. Even if I then go back to the version that that branch is currently on.
That works as a workaround for us for now, but that also means I am not sure if it's going to be consistent for you when you try it..
(The branch is currently on 7.0.0-dev.20251204.1)
I think #2051 and #2070 would have fixed this. So if this repros again, please file new issue with repro steps.
The above user was testing yesterdays build, but I will extract that to a new issue