Potential infinite loop parsing anonymous types.
See original GitHub issueReported originally by @AntonGrekov in https://github.com/dotnet/roslyn/issues/24513.
Anton provided a trace (https://developercommunity.visualstudio.com/t/RoslynCodeAnalysisServiceexe-drains-UPT/10091268) that demonstrates something going very bad with parsing anonymous types (new { ... }
).
Repeating the notes from that issue:
Trace shows teh entirety of the time in:
Interestingly the memory allocation hit is here:
as a massive single outlier in the total memory allocated here:
This indicates one of a few possibilities here:
- You have a truly MASSIVE anonymous-type e.g.
new { ..... OMGHUEG ... }
. - You have a truly MASSIVE number of anonymous-types. e.g.
new { ... } ... new { ... } ... ad infinitum
. - The compiler has a bug where it’s effectively getting into an infinite loop while parsing anonymous-types due to some construct it doesn’t understand. This infinite loop is what is causing the huge spike in CPU and the massive memory allocations as we spin forever, making no progress, constantly allocating nodes for the body of that anonymous type.
‘3’ seems very likely, but i can’t rule out ‘1’ or ‘2’. Would you be willing to zip up all your sources and send them to me? I could then do a simple parsing analysis to see what is likely causing this.
In hte meantime. @333fred @jcouv do you know of any existing issues with parsing anonymous-types, or anything we have fixed in this area that could be causing ‘3’? Looking at the code, i can see we do have a loop that does while (IsMakingProgress(ref lastTokenPosition))
. However, i personally am not familiar/comfortable with the parser’s idioms for loop parsing while ensuring progress to know if this is written correctly. This will likely take further investigation from compiler team here.
Issue Analytics
- State:
- Created a year ago
- Comments:11 (11 by maintainers)
It looks like the user submitted a heap dump in the Developer Community. A file which reproduces the issue (probably one with very large/complex anonymous types, possibly with syntax errors) would also help.
Closing this issue as we’ve seen no reply to the request for more information. If you are able to get the requested information, please add it to the issue and we will retriage it.