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

[yankeeinlondon]

🔎 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.

[lukeapage]

It looks like ts ran out of heap space - that happens on any large project. You need to run node like this:
node --max-old-space-size=4096

And point at the tsc bin endpoint.

Alternately use a env variable to set this switch

https://stackoverflow.com/questions/56742334/how-to-use-the-node-options-environment-variable-to-set-the-max-old-space-size-g

You don’t seem to specify if this is an issue that happened with a new version of ts or from your own changes ?

[RyanCavanaugh]

I'm not seeing the crash, but the diagnostics show you're quite close to running out of memory without the node memory expansion flag mentioned above.

Files:                          746
Lines of Library:             40017
Lines of Definitions:         52752
Lines of TypeScript:          22030
Lines of JavaScript:              0
Lines of JSON:                    0
Lines of Other:                   0
Identifiers:                 100515
Symbols:                     876689
Types:                       908021
Instantiations:             6860194
Memory used:               1521301K <- 1.5 GB

[yankeeinlondon]

@RyanCavanaugh and @lukeapage I was very excited to see this flag but I'm not sure that this is the issue. Using this library (or it's symbols) works without issue (or flags) assuming I can transpile. I did try setting the flag to 4gb, 8gb and then even 16gb and it still crashes in the same place within roughly the same time window (actually 16gb did take a lot longer to crash ... but it still crashed).

I don't know enough about tsc to say this with any confidence but I suspect that something in my source content is pushing tsc into a recursive loop which is why we're running out of memory.

@RyanCavanaugh when you said you weren't seeing the crash, does that mean it was able to be built on your machine?

[yankeeinlondon]

For what it's worth (probably not much):

[RyanCavanaugh]

Well, it worked yesterday, but now I'm seeing the same crash you are :\

[yankeeinlondon]

This is probably a red herring, but I have noticed over the 5.4 - 5.5 timeframe that when I work on this repo that it's inability to transpile flares up in ways that seem a bit random. That said, I'm not sure i've had the same commit be non-deterministic. That's quite odd if that's what you saw.

Here are a few other "factoids":

• All of the types i've seen in VSCode not only work but seem to be responsive and fast (the one exception case I took out on the commit link I sent)
• I have over 600 unit tests which are mainly type tests and in order to test these more systemically I created a rather crude tool using AST to both run type tests across my tests but also to time the AST's ability to analyze a given file's symbols
• this latter capability has proven useful for me when I hit these TS crashes as my tool is still able to give me a read on which files may have more complex types that need attention and more than once it has gotten me over hurdles that allowed me to progress past a crash (though I am stuck now)
• when I find the time I will make this crude tool a bit more user friendly as I suspect a nice Vite plugin that gave realtime TS metrics and pointers might be a really nice things for people doing a lot of inference
• finally should you care to see the raw output of this, you can run pnpm test:types, pnpm audit:runtime, or pnpm audit:types to see it in action (though be forewarned it's crude).

[yankeeinlondon]

Any update on this? I'm completely blocked on a number of repos at the moment (not that that is your issue).

[yankeeinlondon]

Again I know my concerns and yours aren't the same but I have nearly 700 unit tests, I've created a bootstrapped "type tester" and I've split my repo into various sections which reference each other all to stop this repo from not crashing without any indication of where the problem is. It's very frustrating as I have massively improved type performance through this process but all my downstream libraries are unable to utilize the performance benefits along with the new type utilities this library now has in it because I can't build! All the while VS Code is able to infer all the types and all runtime and type tests pass without issue.

[ritschwumm]

i'm sporadically seeing a similar crash with tsc --build (tsc 5.5.4) after switching branches in git for a project with complicated and heavily recursive types - but only when incremental:true or composite:true .

iirc older (?) tsc versions sometimes ran into the 5e6 instantiations (?) instead.

if this is the same problem, what can i do to help? any idea what i could do to reproduce this behaviour reliably?

[yankeeinlondon]

So I wrote a small program to run performance across my repo that produced this issue and this was able to inform me where the issue was coming from. the utility at the heart of the issue wasn't critical for me so I stubbed it out for now but planned on coming back to it to evaluate it some more later. That said, these two commit's represent the "not-working" to "working" transition and while there are a few files changed the real problem file was: `src/runtime/runtime-types/dict.ts`. - Working commit: https://github.com/inocan-group/inferred-types/tree/9f6b6f4084810f813b93b7075106d7ddf439d560 - Not working commit: inocan-group/inferred-types@b12acc6 - Link to `dict.ts` file: https://github.com/inocan-group/inferred-types/blob/aa7db7b1b950dd9810aeb69927e38cda92bbdd39/src/runtime/runtime-types/dict.ts I will try and come back to this file soon and see if anything stands out in it's implementation that might make it crash **tsc** but nothing jumped out at a very quick glance. Ken

…

On Fri, Aug 23, 2024 at 7:15 AM ritschwumm ***@***.***> wrote: i'm sporadically seeing a similar crash with tsc --build (tsc 5.5.4) after switching branches in git for a project with complicated and heavily recursive types. iirc older (?) tsc versions sometimes ran into the 5e6 instantiations (?) instead. if this is the same problem, what can i do to help? any idea what i could do to reproduce this behaviour reliably? — Reply to this email directly, view it on GitHub <#59265 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHPOFJBYQERJAT45QJWWZLZS47WLAVCNFSM6AAAAABK2UT5JSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBXGE4DMNZUGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>