tsc compiler crash on complex project (with tons of tests)

🔎 Search Terms

this one's pretty basic ... it tsc crashes with zero indication on what caused it.

🕗 Version & Regression Information

• This is a crash, used multiple versions of Typescript 5.x but now on 5.5.3 (the latest as of now) I even tried on 5.6.0-dev.20240713 as an act of desperation. All versions appear that I tested appear to behave identically.

Crash while building types, no indication on where in the source this problem originates.

⏯ Playground Link

https://github.com/inocan-group/inferred-types/tree/0ae9b657e4290a292ebb9af19f06dd110b715226

💻 Code

• Running pnpm install && pnpm build should build the project
• the project is 4 source tree's which use references to one another:

• when running the build process you'll find that the "shared constants" compiles right away as does the "type utilities"
• after that the Runtimes utilities are built and this is where it fails
• the error is as follows:

<--- Last few GCs --->

[5193:0x130008000] 32075 ms: Mark-Compact 4042.5 (4131.3) -> 4033.8 (4138.6) MB, 490.83 / 0.00 ms (average mu = 0.625, current mu = 0.249) allocation failure; scavenge might not succeed
[5193:0x130008000] 33278 ms: Mark-Compact 4049.5 (4138.6) -> 4039.6 (4144.3) MB, 1169.50 / 0.00 ms (average mu = 0.330, current mu = 0.027) allocation failure; scavenge might not succeed

<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

1: 0x1041bcb44 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/usr/local/bin/node]
2: 0x1043443ec v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/usr/local/bin/node]
3: 0x104518ac0 v8::internal::Heap::GarbageCollectionReasonToString(v8::internal::GarbageCollectionReason) [/usr/local/bin/node]
4: 0x10451759c v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/bin/node]
5: 0x10450ddb4 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/bin/node]
6: 0x10450e614 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/bin/node]
7: 0x1044f3684 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/usr/local/bin/node]
8: 0x1048db394 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/usr/local/bin/node]
9: 0x104c38c44 Builtins_CEntry_Return1_ArgvOnStack_NoBuiltinExit [/usr/local/bin/node]
10: 0x104bfba10 Builtins_StoreIC [/usr/local/bin/node]

• I have hit this crashing problem a lot with this repo so i've built a lot of tools which inspect the type system and try to help me to identify WHERE the problem is originating from. You can try pnpm run audit:runtime -v --clean and it will

🙁 Actual behavior

crash during garbage collection; no indication regarding relationship to userland code origination.

🙂 Expected behavior

I just want to know WHAT symbol(s) are causing problems so I can dig into them.

Additional information about the issue

In VS-Code I have the intelisense working just fine. I have hundreds of unit tests which test not only runtime values but do type testing as well so I feel pretty confident there aren't any glaring issues.

This used to be just one big repo but because i've had this issue before I split it into dependent sections and this has helped but now with that and all my own investigations I can't tell what is causing the issue.