JavaScript heap out of memory after upgrading to 4.3 #44299
Comments
|
Almost (young object promotion failed Allocation failed) exact same issue. obviously must be something specific about our codebase, but verbose outputs nothing so I dont know where we go from here. Perhaps providing some kind of dump might be useful for someone? Worth noting it happens after a very long time hanging. |
|
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. |
|
@brudil Im using Zod too! |
|
@brudil I am also using Zod! |
|
Interesting, using Zod here as well, 3.1.0 and I can't |
|
I setup a minimal test case like so: import zod from 'zod'
export const SchemaExample = zod.object({
name: zod.string().min(1),
description: zod.string().min(1),
})
export type SchemaExampleType = zod.infer<typeof SchemaExample>Interestingly, in the simple case, this causes "maximum depth" TS errors rather than a hang. Here are the errors: |
|
FWIW I'm not using Zod, but the codebase is quite large. |
|
Interesting. Perhaps its more t do with anything that uses recursive types. |
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 package to 4.2 until this is fixed see microsoft/TypeScript#43249, colinhacks/zod#443, colinhacks/zod#473, microsoft/TypeScript#44299
RyanCavanaugh
added
the
Needs Investigation
|
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. |
|
Introduced in #30639 (cc @weswigham). On the bright side, in that exact commit, the toy repro runs out of memory, so we've made improvements since then. 😄 |
|
Yeah, when we merged that we started exploring more types during relationship checking to test for compatibility which, for generatively expanding types, means manufacturing more types (before we hit somewhat arbitrary limiters) - in the intervening time, we've tightened up on some of those limiters/identities a bit, and that's generally how I've been going about "fixing" it - identify costly structures to compare, figure out how they're dodging our complexity limiters, and the update the complexity limiters to capture them. |
|
I'm getting similar error, and I have a (maybe) simpler repro: import { object, string } from "zod";
const validator = object({
_key: string()
});That's enough to trigger the excessive stack depth error. My guess is that it has something to do with generic inference. |
|
Okay, it took a while, but here's a toy repro with no imports. export declare type ZodFormattedError<T> = T extends [any, ...any] ? {
[K in keyof T]?: ZodFormattedError<T[K]>;
} & {
_errors: string[];
} : T extends any[] ? ZodFormattedError<T[number]>[] & {
_errors: string[];
} : T extends object ? {
[K in keyof T]?: ZodFormattedError<T[K]>;
} & {
_errors: string[];
} : {
_errors: string[];
};
export declare class ZodError<T> {
format: () => ZodFormattedError<T>;
}
declare const c1: ZodError<number>;
const c2: ZodError<string> = c1;Personally, I find it easier to read like this: type ZodFormattedError<T> = T extends [any, ...any]
? { [K in keyof T]?: ZodFormattedError<T[K]>; } & { _errors: string[]; }
: T extends any[]
? ZodFormattedError<T[number]>[] & { _errors: string[]; }
: T extends object
? { [K in keyof T]?: ZodFormattedError<T[K]>; } & { _errors: string[]; }
: { _errors: string[]; };
interface ZodError<T> {
format: () => ZodFormattedError<T>;
}
declare const c1: ZodError<number>;
const c2: ZodError<string> = c1; |
|
Ooh, if you comment out these lines, it OOMs: type ZodFormattedError<T> = T extends [any, ...any]
? { [K in keyof T]?: ZodFormattedError<T[K]>; } & { _errors: string[]; }
: T extends any[]
? ZodFormattedError<T[number]>[] & { _errors: string[]; }
// : T extends object
// ? { [K in keyof T]?: ZodFormattedError<T[K]>; } & { _errors: string[]; }
: { _errors: string[]; };
interface ZodError<T> {
format: () => ZodFormattedError<T>;
}
declare const c1: ZodError<number>;
const c2: ZodError<string> = c1; |
|
And pulling out the intersection with type ZodFormattedError<T> = { _errors: string[]; } & (T extends [any, ...any]
? { [K in keyof T]?: ZodFormattedError<T[K]>; }
: T extends any[]
? ZodFormattedError<T[number]>[]
: T extends object
? { [K in keyof T]?: ZodFormattedError<T[K]>; }
: {});(I think I got that right.) |
|
@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? |
|
is this a zod problem or a ts problem? I feel like this might be more of a ts problem, because something changed in ts 4.3 that broke zod |
|
@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. |
Here's the output I got: See trace analysis |
|
@EvHaus If it were me, I'd try to eliminate that version mismatch for Without the corresponding types file, it's hard to be more specific about which types/packages are causing slowdowns. (I'm not sure why you didn't get that output - maybe it gets skipped if the trace is incomplete.) You can use the |
|
My issue (slowness with CSS types) doesn't happen with latest 4.7 beta |
|
Unfortunately removing the duplicate See trace analysis |
|
@EvHaus That's a very long time to spend checking the babel types and I'd be interested to know which version you're on. Having said that, it seems like there's little benefit in checking them yourself, so I'd probably build with |
|
@amcasey We're using Any ideas what could have changed between 4.5 and 4.6 that could explain this problem? I'm trying to evaluate if it's better to stick to 4.5 or to move to 4.6 with |
|
@EvHaus Notable exception: If you hand-author .d.ts files, you probably do not want Without knowing the specifics, my guess would be that 4.6 does more checking (i.e. catches more bugs) than 4.5 in a way that affects one or more of your dependencies. If you can share an example, I can look for a more specific explanation. If your code isn't available, it's usually possible to isolate a repro using |
|
Not sure what you guys did, but |
|
Also experiencing this with |
|
I'm seeing this with:
Downgrading to |
|
Hello, everyone! I'm getting the same error. {
"compilerOptions": {
"module": "commonjs",
"declaration": true,
"removeComments": true,
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"allowSyntheticDefaultImports": true,
"target": "es2017",
"sourceMap": true,
"incremental": true,
"skipLibCheck": true,
"strictNullChecks": true,
"noImplicitAny": true,
"strictBindCallApply": false,
"forceConsistentCasingInFileNames": false,
"noFallthroughCasesInSwitch": false,
"noUncheckedIndexedAccess": true,
"allowJs": true,
"outDir": "./dist",
"checkJs": false,
},
}In my Mac mini (Monterey, M1 2020, 8GB). When I started the build process, I realised the node consumption exceeded 100% CPU usage. It builds with success, though. Otherwise, in my EC2 instance (Ubuntu 22.04.1 LTS, Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz) shows me this error: I tried to increase the I tried typescript version 4.2.4 and the latest, 4.9.5. Am I doing something wrong? |
Experiencing the same here on my MBP with M2 Pro. |
|
Having this (or similar) issue with zod 3.20.6 and typescript 4.8.2 |
|
I guess there's another issue about |
|
Still getting this issue. I'm getting the following error: when running |
|
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), tsx files: // Changed
<StyledChip variant={variant} {...otherProps}>
// To
<StyledChip
variant={variant as TChipVariants}
{...(otherProps as React.HTMLAttributes<HTMLDivElement>)}
>And // Changed
{...otherProps}
// To
const { sx, ...restProps } = otherProps
...
<StyledRadioGroup {...restProps} >But had to increase max-old-space-size dramatically to 16384 in order to get the relevant errors.. |
|
If anyone needs a quick/temp fix: downgrading to |
|
Using MUI (I'm using MUI v5.14.16) may give the heap-out-of-memory error. Upgrading the TS to I have a util type This may also seem related to the issue when using Zod. export type CreateComponentProps<T = {}> = T & ComponentTestKit & MuiBaseComponent;
export interface MuiBaseComponent {
className?: string;
sx?: SxProps;
}Environment
|
Same kind of issue with |
and others
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.🙁 Actual behavior
It crashed.
🙂 Expected behavior
No crash
The text was updated successfully, but these errors were encountered: