Out of memory

[forabi]

Search Terms:
high memory usage heap react

Code

export type ScheduleProps = {
  // ...
  eventContentComponent?: React.ElementType<EventContentProps>;
  eventRootComponent?: React.ElementType<EventRootProps>;
};

Expected behavior:
Compiled.

Actual behavior:

$ tsc --project . --noEmit

<--- Last few GCs --->

[15840:0x2897f30]    25267 ms: Mark-sweep 1335.2 (1446.8) -> 1327.9 (1449.3) MB, 938.0 / 0.0 ms  (average mu = 0.195, current mu = 0.058) allocation failure scavenge might not succeed
[15840:0x2897f30]    26971 ms: Mark-sweep 1339.7 (1449.3) -> 1332.1 (1450.8) MB, 1650.9 / 0.0 ms  (average mu = 0.096, current mu = 0.031) allocation failure scavenge might not succeed


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x38acc9bdbe1d]
    1: StubFrame [pc: 0x38acc9ba236e]
Security context: 0x23118b41e6e1 <JSObject>
    2: slice [0x23118b406d09](this=0x26806be58fb9 <JSArray[12]>,0)
    3: /* anonymous */(aka /* anonymous */) [0x367b1a96a1f9] [/home/f/Projects/remotelock/react-week-scheduler/node_modules/typescript/lib/tsc.js:~32894] [pc=0x38acca56d751](this=0x2aaba17826f1 <undefined>,t=0x0e1171e59ff9 <Type map = 0x12d8538d48a1>)

Repo: https://github.com/remotelock/react-week-scheduler

Steps to reproduce:

1. Clone repo
2. git checkout 9c64f4f7224d199d9706c4fdec4cd073292c1842
3. yarn
4. yarn check-ts

Replacing React.ElementType here (L25 & 27) with any works around the bug.

[weswigham]

Same root cause as #29949. Turning off strictFunctionTypes should be another blanket workaround until we can fix these comparisons for properties of HOCs to be more efficient.

[panjiesw]

I encountered this in a project part of somewhat big monorepo. It's also a React library project, but I don't know if it's the same cause as the HOCs issue because this particular project doesn't export React component. It does import many types and utility types from 3rd party libraries.

I was trying tsc build mode combined with --incremental. It works previously since TS v3.1

Anyway, even after setting "strict": false, I still got Out of memory error

<--- Last few GCs --->

[12998:0x353c730]    49033 ms: Scavenge 1381.6 (1423.5) -> 1380.7 (1424.0) MB, 4.2 / 0.0 ms  (average mu = 0.333, current mu = 0.317) allocation failure 
[12998:0x353c730]    49039 ms: Scavenge 1381.6 (1424.0) -> 1380.7 (1424.5) MB, 4.6 / 0.0 ms  (average mu = 0.333, current mu = 0.317) allocation failure 
[12998:0x353c730]    49046 ms: Scavenge 1381.7 (1424.5) -> 1380.7 (1425.0) MB, 4.2 / 0.0 ms  (average mu = 0.333, current mu = 0.317) allocation failure 


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x280fd72dbe1d]
Security context: 0x0039a671e6e1 <JSObject>
    1: typeToTypeNodeHelper(aka typeToTypeNodeHelper) [0x30c46bab2291] [/home/panjiesw/dev/workspaces/srin/swuif/node_modules/typescript/lib/tsc.js:~27985] [pc=0x280fd780a88a](this=0x1d70352826f1 <undefined>,type=0x1d1526819d51 <Type map = 0x3691eff0ba1>,context=0x24815e948909 <Object map = 0x34bf4388c0d1>)
    2: symbolToParameterDeclaration(aka symbolToPar...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x8daaa0 node::Abort() [node]
 2: 0x8daaec  [node]
 3: 0xad73ce v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
 4: 0xad7604 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
 5: 0xec4c32  [node]
 6: 0xec4d38 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [node]
 7: 0xed0e12 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [node]
 8: 0xed1744 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 9: 0xed43b1 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [node]
10: 0xe9d834 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [node]
11: 0x113cf9e v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [node]
12: 0x280fd72dbe1d

The tsc CLI stopped at 1.4GB RAM consumption as seen in the log. This also made VSCode eats a lot of RAM, topping at around 2.1GB, but it eventually settled down, probably that's the amount of RAM needed to parse the project.

[Ryan1729]

I ran into a similar memory issue which was causing tsc to get killed on CI due to lack of memory. I refactored the code to use the newer React.createRef() API and typed all my refs as RefObject<T>, whose type doesn't involve { bivarianceHack(instance: T | null): void }["bivarianceHack"] and the memory usage went down enough that my CI build passes again.

I'm posting this here in case this helps someone else who also didn't want to disable strictFunctionTypes.

[unional]

Another memory issue example:

https://circleci.com/gh/unional/komondor/988

This happens on Node 8-10, but pass in 11.

[kalbert312]

Ran into same problem as @panjiesw. Also importing utility types and the like from many projects. It would just continuously climb no matter what. Turning off incremental compilation fixed it.

EDIT: Using create-react-app, so changing fork-ts-checker-webpack-plugin's option using rescripts via:

        config = editWebpackPlugin(
		(p) => {
			p.memoryLimit = 4096;
			p.useTypescriptIncrementalApi = false;
			return p;
		},
		"ForkTsCheckerWebpackPlugin",
		config
	);

was needed after the command line tsc no longer ran out of memory.

I did some debugging on the compiler and it seemed get stuck in an infinite loop on the DeepReadonly/DeepPartial utility types of ts-essentials package while incremental was turned on.

[panjiesw]

I found the source in my case btw. It's because of the changes in how generics work in 3.4 and later 3.5, and also the type definitions of imported libraries. Few changes to make generics explicit help my projects build

[hardfist]

met same problem and I investigate using llnode
v8 bt result

v8 findjsobject results

It's triggered by using https://github.com/immerjs/immer, after I delete the code using ok, it's fine

[weswigham]

@hardfist your example appears to be running OOM in a different phase of complication than the rest of this thread (so almost definitely has a different root cause) - you should open a new issue.

[yxliang01]

I think would be great if TypeScript can figure out the possible locations in the code that cause this out of memory problem. It's really hard to pinpoint...

[Hotell]

We're experiencing similar issue #33612 (comment)

[szkrd]

With 3.7 the memory usage is insane (during npm test from 5-6GB it eats the whole 16GB and the kernel starts swapping like crazy), but with ts@next everything's smooth as butter 👍

[amitdahan]

Getting this as well merely by having @types/babel__traverse in my node_modules (no skipLibCheck).

Starting with this commit (@types/[email protected]+):
DefinitelyTyped/DefinitelyTyped@4fccaa0#diff-a540d520f49a14b1742cdf4f1a2d61b0

[bradzacher]

I've got a self-contained concrete repo for this with no libraries required:

• switch to node v10.x.
• checkout feat: add package scope-manager typescript-eslint/typescript-eslint#1939 (specifically this commit)
• yarn install --ignore-scripts (need the --ignore-scripts or it'll attempt to do a build post install)
• cd packages/typescript-estree
• yarn build
• observe OOM.

I think that this is due to the changes I made here, which added the following:

type SimpleTraverseOptions = {
  [type in AST_NODE_TYPES]?: (
    node: Extract<TSESTree.Node, { type: type }>,
    parent: TSESTree.Node | undefined,
  ) => void;
};

TSESTree.Node is a large discriminated union of ~160 object types.
AST_NODE_TYPES is a large enum of ~150 values.
Each value in AST_NODE_TYPES has 1 (or more) matching items in the TSESTree.Node union.

The intention behind the type was to do something similar to this type without enumerating it all by hand.

Example usage of the type is:

const x: SimpleTraverseOptions = {
  MemberExpression(node): void { ... }
//                 ^^^^ automatically typed as TSESTree.MemberExpression
};

Versions tested:

• TS v3.8.3
  • v8.12.0 - OOM
  • v10.17.0 - OOM
  • v12.14.1 - compiles fine (~20.9s, compared to master which is ~6.3s).
  • v13.13.0 - compiles fine (~18.5s, compared to master which is ~6.2s).
• TS v3.9.1-rc
  • v8.12.0 - OOM
  • v10.17.0 - OOM
  • v12.14.1 - compiles fine (~18s, compared to master which is ~6s).
  • v13.13.0 - compiles fine (~18.1s, compared to master which is ~6s).

[nathan5x]

Experiencing the same issue. Any updates / solutions / recommendations?

[weswigham]

The original example no longer OOMs on latest TS. If you have a new, self-contained example on latest TS, please open a new issue to let us know. ❤️