Open yankeeinlondon opened 1 month ago
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
You donβt seem to specify if this is an issue that happened with a new version of ts or from your own changes ?
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
@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?
For what it's worth (probably not much):
Well, it worked yesterday, but now I'm seeing the same crash you are :\
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":
pnpm test:types
, pnpm audit:runtime
, or pnpm audit:types
to see it in action (though be forewarned it's crude).Any update on this? I'm completely blocked on a number of repos at the moment (not that that is your issue).
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.
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?
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: https://github.com/inocan-group/inferred-types/commit/b12acc663d4f5c39077f7b443f32a56b528434bc
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 https://github.com/microsoft/TypeScript/issues/59265#issuecomment-2307186741, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHPOFJBYQERJAT45QJWWZLZS47WLAVCNFSM6AAAAABK2UT5JSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBXGE4DMNZUGE . You are receiving this because you authored the thread.Message ID: @.***>
π Search Terms
this one's pretty basic ... it
tsc
crashes with zero indication on what caused it.π Version & Regression Information
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
pnpm install && pnpm build
should build the project[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]
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.