TypeScript: JavaScript heap out of memory after upgrading to 4.3
Bug Report
🔎 Search Terms
Memory
🕗 Version & Regression Information
After upgrading to 4.3.2 I get a “JavaScript heap out of memory” exception when i try to run tsc. Downgrading to 4.2.4 does not yield the same error.
<--- Last few GCs --->
[43233:0x108008000] 75872 ms: Scavenge 2043.5 (2049.9) -> 2043.0 (2049.9) MB, 6.6 / 0.0 ms (average mu = 0.119, current mu = 0.127) allocation failure
[43233:0x108008000] 75927 ms: Scavenge 2043.8 (2049.9) -> 2043.3 (2050.2) MB, 6.5 / 0.0 ms (average mu = 0.119, current mu = 0.127) allocation failure
[43233:0x108008000] 75986 ms: Scavenge 2044.0 (2050.2) -> 2043.5 (2050.4) MB, 7.0 / 0.0 ms (average mu = 0.119, current mu = 0.127) allocation failure
<--- JS stacktrace --->
==== JS stack trace =========================================
0: ExitFrame [pc: 0x100930c99]
Security context: 0x390dbb3008a1 <JSObject>
1: getIntersectionType(aka getIntersectionType) [0x390df5b65bb9] [/.../node_modules/typescript/lib/tsc.js:~47588] [pc=0x1a0124246ed4](this=0x390d982804a9 <undefined>,0x390d7a08df51 <JSArray[18]>,0x390d982804a9 <undefined>,0x390d982804a9 <undefined>)
2: getCrossProductIntersections(aka getCrossProductIntersections) [0...
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 0x10007e9b3 node::Abort() [/usr/local/bin/node]
2: 0x10007eb37 node::OnFatalError(char const*, char const*) [/usr/local/bin/node]
3: 0x100176337 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
4: 0x1001762d3 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
5: 0x1002fa485 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/usr/local/bin/node]
6: 0x1002fbb54 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [/usr/local/bin/node]
7: 0x1002f8a27 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/usr/local/bin/node]
8: 0x1002f6a0d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/bin/node]
9: 0x1002f58c1 v8::internal::Heap::HandleGCRequest() [/usr/local/bin/node]
10: 0x1002bac3f v8::internal::StackGuard::HandleInterrupts() [/usr/local/bin/node]
11: 0x1005f7b6c v8::internal::Runtime_StackGuard(int, unsigned long*, v8::internal::Isolate*) [/usr/local/bin/node]
12: 0x100930c99 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/usr/local/bin/node]
13: 0x1a0124246ed4
🙁 Actual behavior
It crashed.
🙂 Expected behavior
No crash
About this issue
- Original URL
- State: open
- Created 3 years ago
- Reactions: 43
- Comments: 47 (16 by maintainers)
Commits related to this issue
- fix: downgrade Typescript to 4.2.4 zod is incompatible with Typescript 4.3.x due a change in 4.3 for evaluating deep complex types. Since we do not use any 4.3 features (yet), lock typescript packag... — committed to opengovsg/FormSG by karrui 3 years ago
- Lock and update deps to fix build memory leak - I've been to hell and back, and haven't managed to pinpoint all of the exact dependencies that cause the build to leak (or more likely: attempt to over... — committed to espoon-voltti/evaka by mikkopiu 3 years ago
We’re experiencing this against both our front and backend applications which is interesting as they share little code. By any chance is anyone else here using Zod? It’s perhaps the most type-complex library which we’re using in both.
FWIW I’m not using Zod, but the codebase is quite large.
I’m also having issues moving from
4.5.5to4.6.2while doing a type checktsc --noEmit -p tsconfig.jsonand one component is taking a crazy amount of time when usually the whole process takes between 3 and 8 seconds.The compoent involved is a
Buttoncreated with@stitches/reactso I think there is a pattern here that something is wrong with libraries that are using CSS types perhaps.I followed the instructions https://github.com/microsoft/TypeScript/wiki/Performance#performance-tracing but no idea if this is a problem on my side or a regression in Typescript 👀
Adding this: the memory usage is constantly increasing but eventually the process ends (I’m on OS X with 32GB RAM)
`$ npx analyze-trace trace`
Component code
Running into OOM errors after upgrading from 4.5.5 to 4.6.2. We’re not using zod. Curious if something changed from 4.5 to 4.6 that could cause this problem?
I’ve seen this repeatedly too in different project (can’t share the code yet). E.g. usages suretype and meta-types (both of which I’m the author of). (Again, not in these packages per se, but usages of them).
I’ve stumbled on this many times from at least 3.x. I think TypeScript would benefit from a rather massive bump in meta programming support and much higher limits. I remember back when C++ template programming was unbearably slow, and then about 10 years ago, compilers made a huge leap and started handling meta programming several orders of magnitude faster. I’d love for this to get prio over new features in the language 🙏
I’m going to investigate Zod, since there’s a repro. Hopefully, the underlying issue will turn out to be the same as @dagstuan’s.
I’ve created a minimal repro here that demonstrates this using Material UI as well. Basically, I’m doing these things:
SomeComponentPropsSomeComponentProps(my intent here was to make the base props available from within the wrapper component)SomeComponentPropsinside the wrapper component.If I remove the intersection of prop types or the attempt to merge values into one of the base component’s props, all compiles well.
I’ve tried this with
ts@next,ts@4.5.4,ts@4.5.2, andts@4.2.4, as well asnode 14.18.2and16.5.0with the same results. It could just be that I just shouldn’t be trying to “forward” base component props in the way that I have, but still, I don’t think it should cause a fatal error. It should be detected and thrown instead.Here’s the code from the repro that produces the problem for me:
Any news on this? I attempted to re-run my repro with 4.4.0-beta and it still fails.
Still getting this issue. I’m getting the following error:
when running
tsc --pretty --noEmiteven if I set the space size like the following:@autumnblazey It’s a TS problem, but a zod PR might help people until a new version of TS is released. Also, the proposed change to zod will likely make it faster even after the TS fix.
Having this (or similar) issue with zod 3.20.6 and typescript 4.8.2
Just a note that Zod 3.2 is out and it now works. Still, theres some underlying issue here.
I’ve also had an issue with moving to typescript ~5.1 (or even ~5.0 TBH) in a React components library (it uses mui), Here’s how I resolved the
TS2590: Expression produces a union type that is too complex to representerror:tsx files:
And
But had to increase max-old-space-size dramatically to 16384 in order to get the relevant errors… I hope it helps anyone…
I guess there’s another issue about
JavaScript heap out of memoryerrors over here (about4.9.3):I’m seeing this with:
typescript: 4.9.4zod: 3.21.4Downgrading to
zod: 3.21.2resolves the issue. Upgrading totypescript: 4.9.5doesn’t make a difference.My issue (slowness with CSS types) doesn’t happen with latest 4.7 beta
npm i typescript@beta👀@dagstuan Fantastic! I’ll leave it up to @weswigham to decide whether you’re seeing the same underlying issue (I suspect so).
@amcasey sure thing, thank you for the help!
I ran the trace and figured out that a utility type I wrote a year or so ago to help with
redux-formtypings (DeepPartialExceptArrays<T>) is causing the issue, along with two type guards. I created a repro here. If you leave the tab open it eventually crashes. Without the type guards it works fine, and it also works fine in TS 4.2Edit: Oh, and it also works fine with only one of the type guards. The issue seems to arise with the intersection type generated by applying both type guards.
I run into the same issue with https://github.com/unional/type-plus. Essentially similar issue with
zod@weswigham Is there something smart we can do with the depth limit in the the toy repros? And does my mitigation look correct enough to submit as a PR to zod?
Ooh, if you comment out these lines, it OOMs:
Okay, it took a while, but here’s a toy repro with no imports.
Personally, I find it easier to read like this: