-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Out of memory crash with noErrorTruncation #37230
Labels
Milestone
Comments
DanielRosenwasser
added
the
Crash
For flagging bugs which are compiler or service crashes or unclean exits, rather than bad output
label
Mar 5, 2020
I have a similar issue in version 3.8.3:
|
@alumni - that dump looks like it occurs in |
Verified that this is fixed by #37461. |
kyliau
pushed a commit
to bazelbuild/rules_typescript
that referenced
this issue
Mar 31, 2020
TypeScript runs out of memory trying to produce a human readable diagnostic in certain situations (infinitely recursing through anonymous type), see microsoft/TypeScript#37230. That's a bug, but more generally speaking, the default TypeScript behaviour is to run with error truncation. That's for a reason: some errors are much more readable with truncation. TypeScript's core team made the call that error truncation is generally a good idea, so we should follow along unless we have strong data indication otherwise (which we don't). Beyond that, error truncation being the default means it is the better tested path, so we'll probably save us some trouble in the future by keeping it enabled. PiperOrigin-RevId: 299096788
alexeagle
pushed a commit
to alexeagle/rules_nodejs
that referenced
this issue
Oct 17, 2020
TypeScript runs out of memory trying to produce a human readable diagnostic in certain situations (infinitely recursing through anonymous type), see microsoft/TypeScript#37230. That's a bug, but more generally speaking, the default TypeScript behaviour is to run with error truncation. That's for a reason: some errors are much more readable with truncation. TypeScript's core team made the call that error truncation is generally a good idea, so we should follow along unless we have strong data indication otherwise (which we don't). Beyond that, error truncation being the default means it is the better tested path, so we'll probably save us some trouble in the future by keeping it enabled. PiperOrigin-RevId: 299096788
alexeagle
pushed a commit
to alexeagle/rules_nodejs
that referenced
this issue
Oct 18, 2020
TypeScript runs out of memory trying to produce a human readable diagnostic in certain situations (infinitely recursing through anonymous type), see microsoft/TypeScript#37230. That's a bug, but more generally speaking, the default TypeScript behaviour is to run with error truncation. That's for a reason: some errors are much more readable with truncation. TypeScript's core team made the call that error truncation is generally a good idea, so we should follow along unless we have strong data indication otherwise (which we don't). Beyond that, error truncation being the default means it is the better tested path, so we'll probably save us some trouble in the future by keeping it enabled. PiperOrigin-RevId: 299096788
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
TypeScript Version: Version 3.9.0-dev.20200305
Search Terms:
JavaScript heap out of memory, oom, noErrorTruncation
Code
Install the required types (
npm install @types/jasmine @types/figma
), then runtsc --noErrorTruncation
Expected behavior:
Report an error due to
frames
not having the same type asselection
.Actual behavior:
TypeScript crashes with OOM:
I strongly suspect TypeScript runs into an (at least effectively) infinite loop here: this crashes with 2 GB max heap for node, but also with 8 GB.
From a bit of debugging, it seems that TypeScript endlessly recurses through Jasmine's
ExpectedRecursive<T>
type:As it tries to produce a diagnostic string via
typeToTypeNode
, it keeps coming through the anonymous inline type here.Playground Link: n/a (though probably possible to reduce the required type signatures from
@types
)Related Issues: n/a
The text was updated successfully, but these errors were encountered: