Repository navigation
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory #18411
Description
TypeScript Version: nightly (2.6.0-dev.20170912)
Code
{
"compilerOptions": {
"module": "system",
"jsx": "react",
"target": "es5",
"moduleResolution": "node",
"allowSyntheticDefaultImports": true,
"newLine": "lf",
"allowJs": false,
"noImplicitAny": true,
"baseUrl": "./",
"noEmitOnError": true,
"sourceMap": true,
"alwaysStrict": true,
"inlineSourceMap": false,
"paths": {
"*": [
"node_modules/@types/*"
]
},
"lib": [
"dom",
"es2015",
"es5"
]
}
}07:28:49 - File change detected. Starting incremental compilation...
<--- Last few GCs --->
[1592:000002842FE68000] 7027823 ms: Mark-sweep 1401.5 (1465.4) -> 1401.5 (1465.4) MB, 4599.6 / 0.0 ms last resort
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0000033CF2C1CEA9 <JSObject>
1: set [native collection.js:~247] [pc=000000C2A8FE6697](this=000000F425FBE6F1 <Map map = 000003AA6FD983B9>,p=000003A9ED17AB21
<String[9]: @Telefone>,x=000003A9ED17AB51 <Type map = 000003AA6FDC6CF9>)
2: getLiteralType(aka getLiteralType) [C:\nodejs\node_modules\typescript\lib\tsc.js:~24883] [pc=000000C2A8D93E76](this=0000033C
F2C02241 <undefined>,value=000000CEC1A9C961 <String[8]: Telef...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
Expected behavior:
Not crash
Actual behavior:
TS in watch mode is randomly crashing with the above stacktrace. I can't figure out what is making it crash. I'm using vscode, but the watch mode is tsc -w -p tsconfig.json
per Nathan Shively-Sanders (@sandersn) recommendation (in #17112 (comment)) opening a new issue about the same error name, but different stack
Activity
mhegazy commentedon Sep 12, 2017
Paulo Cesar (@pocesar) can you share your sources with us? we are open to do this by email, or sign any required NDAs.
sandersn commentedon Sep 12, 2017
Can you also try
--diagnosticsto see how many types are being created when compilation does succeed?pocesar commentedon Sep 12, 2017
just crashed with another stacktrace
mhegazy commentedon Sep 12, 2017
The stack trace is inconsequential here. the process runs out of memory, it does not really matter where it crashes, what matters is why is it filling up memory.
pocesar commentedon Sep 12, 2017
it will crash again in a couple of minutes, I'll see if anything changes
mhegazy commentedon Sep 12, 2017
so it does not crash without
--watch?pocesar commentedon Sep 12, 2017
so far I've been able to build without watch, but when using
-wit randomly crashes after a couple of compilationsthe memory is ever increasing though
mhegazy commentedon Sep 12, 2017
aah.. that indicates there is a memory leak for
--watch. do you see this with other projects?pocesar commentedon Sep 12, 2017
yes, it usually reaches a point where my machine slows to a crawl, and even vscode crashes (because I have 5 editors opened, all with TSC with watch, using nightly for all of them, even for vscode)
taoqf commentedon Sep 13, 2017
try this:
node --max-old-space-size=4096 ./node_modules/.bin/tscmay work for you.
23 remaining items
shepmaster commentedon Oct 26, 2017
Sheetal Nandi (@sheetalkamat) I am seeing it even without
--watch. One thing I did notice is that also I see this behavior with only upgrading ts-loader. When I was originally doing this set of upgrades, I noticed a slowdown when I upgraded ts-loader, but then ran out of memory when upgrading TypeScript. It's possible that TS 2.5+ uses a bit more memory than 2.4 (which sounds like a known issue) and something about ts-loader 3.x uses a lot more memory and the combination of the two of them caused running out of memory.I don't know how having upgraded ts-loader would affect the performance of
tscthough, even when not directly invoking webpack.shepmaster commentedon Oct 26, 2017
Are the warnings like
Normal / to be expected? It seems strange that there's some kind of configuration that would be overwriting input files...
In fact, when I add some options to extend the memory available (
node --max-old-space-size=8192 /Users/shep/Projects/integer32/playground/ui/frontend/node_modules/.bin/tsc), I get a lot of errors:Perhaps I have some poor configuration that is reading my output directory as input files... In fact, I have
65Mof output files, which might be triggering #17112. I'll see if I can adjust my configuration to properly ignore output files. This might explain why you don't see the same problem — you don't have the same old build artifacts laying around that I do.electricessence commentedon Oct 28, 2017
Just a note... This error still happens for me in 2.7.0-dev.20171027.
I have to revert to 2.3.2 for my code to compile (and it does effortlessly).
mhegazy commentedon Oct 30, 2017
electricessence can you share the project
electricessence commentedon Nov 1, 2017
Mohamed Hegazy (@mhegazy) https://github.com/electricessence/TypeScript.NET
The project compiles in Webstorm for the existing tsconfigs with 2.7. But I'm dependent on gulp to render my distributions and run tests. The area where it gets problematic is in /source/System.Linq where the Linq.ts lib tries to reconcile the extensive interface signature. If I rip out the guts of the interface, it will compile (although still quite slowly relative to 2.3.2)
mhegazy commentedon Nov 1, 2017
electricessence seems like a separate issue..
mhegazy commentedon Nov 1, 2017
--noStrictGenericChecksshould get you going in the time being.mhegazy commentedon Nov 1, 2017
filed #19662 to track that one.
electricessence commentedon Nov 5, 2017
Ok I will try
--noStrictGenericChecksmhegazy commentedon Nov 9, 2017
closing for now. please reopen if you are still running into issues.
electricessence commentedon Nov 16, 2017
I'm following it on #19662,