Repository navigation
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory #18411
Description
Activity
Paulo Cesar (@pocesar) can you share your sources with us? we are open to do this by email, or sign any required NDAs.
Can you also try
--diagnosticsto see how many types are being created when compilation does succeed?just crashed with another stacktrace
13:38:16 - File change detected. Starting incremental compilation... <--- Last few GCs ---> [13348:000001CC04D09180] 8048988 ms: Mark-sweep 1403.5 (1469.2) -> 1403.5 (1469.2) MB, 3311.7 / 0.0 ms last resort <--- JS stacktrace ---> ==== JS stack trace ========================================= Security context: 000002E66029CEA9 <JSObject> 1: getTypeReferenceId(aka getTypeReferenceId) [C:\nodejs\node_modules\typescript\lib\tsc.js:~26377] [pc=0000014DCA819BD0](this= 000002E660282241 <undefined>,type=000002FC83FFBC51 <Type map = 0000008AEC429EF9>,typeParameters=00000388F03E8951 <JSArray[1]>,depth =000002E660282241 <undefined>) 2: arguments adaptor frame: 2->3 3: getRelationKey(aka getRelationKey) [C:\nodejs\node_modules\... FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory The terminal process terminated with exit code: 3 Terminal will be reused by tasks, press any key to close it.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.
Files: 121 Lines: 64003 Nodes: 261277 Identifiers: 88809 Symbols: 136598 Types: 34024 Memory used: 146529K I/O read: 0.85s I/O write: 0.04s Parse time: 2.95s Bind time: 1.58s Check time: 5.19s Emit time: 1.21s Total time: 10.92s 14:09:01 - Compilation complete. Watching for file changes.it will crash again in a couple of minutes, I'll see if anything changes
so it does not crash without
--watch?so far I've been able to build without watch, but when using
-wit randomly crashes after a couple of compilations14:24:33 - File change detected. Starting incremental compilation... Files: 121 Lines: 64003 Nodes: 261277 Identifiers: 88809 Symbols: 136598 Types: 34024 Memory used: 197127K I/O read: 0.01s I/O write: 0.01s Parse time: 1.15s Bind time: 0.02s Check time: 5.19s Emit time: 0.95s Total time: 7.31s 14:24:41 - Compilation complete. Watching for file changes. 14:42:00 - File change detected. Starting incremental compilation... Files: 121 Lines: 64004 Nodes: 261277 Identifiers: 88809 Symbols: 136598 Types: 34024 Memory used: 242675K I/O read: 0.00s I/O write: 0.02s Parse time: 0.60s Bind time: 0.02s Check time: 4.27s Emit time: 0.74s Total time: 5.62s 14:42:05 - Compilation complete. Watching for file changes.the memory is ever increasing though
aah.. that indicates there is a memory leak for
--watch. do you see this with other projects?- assigned and unassigned
on 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)
Files: 121 Lines: 64004 Nodes: 261277 Identifiers: 88809 Symbols: 136598 Types: 34024 Memory used: 329374K I/O read: 0.00s I/O write: 0.00s Parse time: 0.84s Bind time: 0.02s Check time: 3.48s Emit time: 0.61s Total time: 4.95s 15:25:30 - Compilation complete. Watching for file changes.try this:
node --max-old-space-size=4096 ./node_modules/.bin/tsc
may work for you.23 remaining items
Are you seeing issue only when doing tsc --watch or even without watch?
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.Are the warnings like
error TS5055: Cannot write file 'c:/temp/rust-playground/ui/frontend/postcss.config.js' because it would overwrite input file.
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:error TS5055: Cannot write file '/Users/shep/Projects/integer32/playground/ui/frontend/build/assets/manifest-f92a2fa07a675799acdf.js' because it would overwrite input file.
error TS5055: Cannot write file '/Users/shep/Projects/integer32/playground/ui/frontend/build/assets/manifest-fae5d6465c73b7dba2a5.js' because it would overwrite input file.
error TS5055: Cannot write file '/Users/shep/Projects/integer32/playground/ui/frontend/build/assets/manifest-fbeebc437ed33ba9cb03.js' because it would overwrite input file.
error TS5055: Cannot write file '/Users/shep/Projects/integer32/playground/ui/frontend/build/assets/manifest-fd16a06130fa46122d18.js' because it would overwrite input file.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.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).electricessence can you share the project
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)
electricessence seems like a separate issue..
--noStrictGenericChecksshould get you going in the time being.filed #19662 to track that one.
Ok I will try
--noStrictGenericChecksclosing for now. please reopen if you are still running into issues.
I'm following it on #19662,
- locked and limited conversation to collaborators
on Jun 14, 2018
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" ] } }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.jsonper Nathan Shively-Sanders (@sandersn) recommendation (in #17112 (comment)) opening a new issue about the same error name, but different stack