TypeScript: Out of memory

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:

Clone repo
git checkout 9c64f4f7224d199d9706c4fdec4cd073292c1842
yarn
yarn check-ts

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

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 17
Comments: 15 (6 by maintainers)

Most upvoted comments

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

+11

nathan5x on May 20, 2020

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…

yxliang01 on Sep 26, 2019

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.

kalbert312 on Jul 6, 2019

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. ❤️

weswigham on Oct 12, 2020

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.

panjiesw on Apr 1, 2019

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.

weswigham on Mar 26, 2019