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.