Repository navigation
CALL_AND_RETRY_LAST Allocation failed on 3.5.0-rc #31441
Description
TypeScript Version: 3.5.0-rc
Search Terms: CALL_AND_RETRY_LAST Allocation failed 3.5.0-rc
Code
This is a private code base so I'll send an email to Daniel Rosenwasser with a zip.
It contains roughly 600 JavaScript files and 150 TypeScript files (we're mid-conversion!).
Expected behavior:
Compiles correctly, as it did in 3.4.2
Actual behavior:
yarn run v1.15.2
$ tsc
<--- Last few GCs --->
[146:0x288cec0] 194648 ms: Mark-sweep 1371.8 (1450.0) -> 1371.8 (1450.0) MB, 899.4 / 0.0 ms allocation failure GC in old space requested
[146:0x288cec0] 195547 ms: Mark-sweep 1371.8 (1450.0) -> 1371.8 (1410.5) MB, 898.9 / 0.0 ms last resort GC in old space requested
[146:0x288cec0] 196415 ms: Mark-sweep 1371.8 (1410.5) -> 1371.8 (1410.5) MB, 868.2 / 0.0 ms last resort GC in old space requested
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0x12ae99a57c1 <JSObject>
1: set(this=0x3f5e79846d91 <Map map = 0x37e9c78848d9>,0x1fc46c124e61 <String[47]: 6,78748,78757,78774,8,78793,78818,7,78838,78852>,0x1fc46c124e89 <Type map = 0x27f5ecd0eee1>)
2: getIntersectionType(aka getIntersectionType) [/root/project/node_modules/typescript/lib/tsc.js:~33449] [pc=0x3548967bf825](this=0xa86fe2022d1 <undefined>,types=0x1fc46c124a99 <JSArray[10]>,aliasSymbol=0xa86fe2022d...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: node::Abort() [/usr/local/nvm/versions/node/v8.10.0/bin/node]
2: 0x11e73ec [/usr/local/nvm/versions/node/v8.10.0/bin/node]
3: v8::Utils::ReportOOMFailure(char const*, bool) [/usr/local/nvm/versions/node/v8.10.0/bin/node]
4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/usr/local/nvm/versions/node/v8.10.0/bin/node]
5: v8::internal::Factory::NewFixedArray(int, v8::internal::PretenureFlag) [/usr/local/nvm/versions/node/v8.10.0/bin/node]
6: v8::internal::OrderedHashTable<v8::internal::OrderedHashMap, 2>::Allocate(v8::internal::Isolate*, int, v8::internal::PretenureFlag) [/usr/local/nvm/versions/node/v8.10.0/bin/node]
7: v8::internal::OrderedHashTable<v8::internal::OrderedHashMap, 2>::Rehash(v8::internal::Handle<v8::internal::OrderedHashMap>, int) [/usr/local/nvm/versions/node/v8.10.0/bin/node]
8: v8::internal::OrderedHashTable<v8::internal::OrderedHashMap, 2>::EnsureGrowable(v8::internal::Handle<v8::internal::OrderedHashMap>) [/usr/local/nvm/versions/node/v8.10.0/bin/node]
9: v8::internal::Runtime_MapGrow(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/nvm/versions/node/v8.10.0/bin/node]
10: 0x354895e842fd
Aborted (core dumped)
error Command failed with exit code 134.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Exited with code 134
Related Issues: #16834
Activity
weswigham commentedon May 20, 2019
I think your example's maybe similar to #30050. Minimally, I can confirm that the work we're spending all our time doing before we OOM is intersection construction. #31476 is not sufficient to fix the underlying issue there (which from #30050 is, simply put, 2^
len(keyof React.ReactHTML)combinations of possiblereftypes is wholly unreasonable). I can also at least confirm that deleting@types/reactgets your project back into a state where it finishes a build, as does simply reducing the number of elements in theReactHTMLinterface in thereactdeclaration file.weswigham commentedon May 20, 2019
Yeah, it's ultimately the same - your content container is a HOC which takes a
keyof ReactHTML, and checking the props on that component is huuuuuuuuugely expensive (since it's really a union of over 100 components). Checking 100 calls usually wouldn't be that bad; but our intersection/union normalization process expands the types for things like therefmember or theonChangehandler when we compare them memberwise, resulting in us attempting to create unions with more members than we can possibly fit in memory. 😄Specifically, we probably end up making this type when we try to get the contextual type for a prop for the
refexample - in your example, it happens when we go to attempt to see if we need to report excess property errors on the call. At least for your example, I think we might be able to do better by deferring when we build the types of union properties.