-
Notifications
You must be signed in to change notification settings - Fork 730
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
Ctrl+Hover over an OCI module path causes the extension to get stuck with extremely high CPU & memory utilization #13606
Comments
To debug this further, I think we'd need a memory dump. I suggest we keep this open, and next time you run into it (or anyone else does), please capture a memory dump using these instructions. The memory dump may contain sensitive information, so please do not share it directly on GitHub. Reach out to me via email (antmarti at microsoft dot com), and I'd be happy to set up a way to share it securely. |
Boop. I'll provide more information if I encounter this issue next time. |
I've encountered this again, I'll be contacting @anthony-c-martin over email.
|
Yes, it always happens when having bicepparam files. I basically have 3-5 or more VSC windows opened. One of those windows is always a project where I have only bicepparam files. Usually have a few such files open in that window. They either reference bicep registry files or the using statement is empty string. The project itself contains hundreds of bicepparam files. I cannot understand when exactly happens but when I work on that project I usually add the bicep registry reference in the using statement or force restore in order to update the reference. The other projects (VSC windows) are only with bicep files and for them I do not notice that problem. I know that this is the exact window/process because when I kill it VSC asks me if I want to re-open it. I will enable the tracing and see if it appears again I can save the results. If it contains sensitive information will send information I will send it in private. |
@jtomkiew-mng looking at your memory dump, one thing that is very unusual is that there's a huge number of queued language server requests (almost 1.3 million!). Of those I've checked, the vast majority appear to be of kind So my initial instinct here is that the VSCode extension is getting caught in some sort of loop where it is spamming the language service with requests to get an external source file, and the service is simply unable to keep up with the rate of requests coming through. This could also fit with the odd behavior @slavizh was seeing in the gif where it looked like diagnostics were constantly being regenerated, and "external source file" lookups are only relevant for registry modules. @StephenWeatherford can you think of anything that could be going on here? |
FYI, in our setup, we have a bunch of |
2024-04-05T062950.784Z info Current.txt |
I managed to repro this myself! Steps:
I can also confirm that this occurs without external sources functionality enabled - in @slavizh's example, there are no requests of type This seems possibly related to microsoft/vscode#78453. I think we might need guidance from VSCode on how to handle this better. It's worth looking over some of the PRs linked in the above issue for how this was handled in other language servers. It's also not clear to me whether this is a regression in VSCode, or has always been the case. While we figure out how to solve the root cause, the simplest workaround I know of for now is to reload the window - that'll kill the language service and start a new one: |
@anthony-c-martin Can you still repro with your example above? With 1.88.1 (stable) and 1.89.0-Insider, I don't see the doc getting closed at all, no matter how many times I cmd+hover:
|
No - I can no longer repro this! I'm also using VSCode 1.88.1. |
Cool! @jtomkiew-mng @slavizh I'm going to close for now, since it appears to have been fixed (probably by vscode, 1.88.1+). But please feel free to reopen if it's still an issue. Thanks! |
@StephenWeatherford I had experienced the issue yesterday with 1.88.1. Had to kill the .net process and the VSC window. |
@StephenWeatherford hm, from a 0% CPU usage on a single VSCode
If I do I would say it still is an issue. |
Thanks for confirming this is still a problem - I've re-opened the issue. |
Thanks. I guess I'll need a way to repro. Can you repro with Anthony's simple .bicep example? Or other public repo. Anything else that might help? Thanks! |
@StephenWeatherford yes, the example reproduces it as well on my end: VSCode version info:
|
Seeing this in telemetry as an abnormally high occurences of vs-code/externalsourcerequest/success. |
Does this occur consistently? No, from time to time.
Repro steps:
I have no repro steps (this is a terrible bug report, I know), but I use Bicep through VSCode, and from time to time I notice my laptop stops charging (while being connected) which is caused by Bicep .NET host process going "insane", constantly recycling memory (up to 20GB, then back to 10GB over a minute or so).
I recently (this week) did
az bicep upgrade
, not sure if related.Last time I've encountered this was about 4-6 months ago.
Feel free to ask for details, as I have no idea what should I provide here.
Error
Action: bicep.lsp-error
Error type: Error
Error Message: Error: write EOF
Version: 0.25.53
OS: win32
OS Release: 10.0.22631
Product: Visual Studio Code
Product Version: 1.86.2
Language: en
Call Stack
The text was updated successfully, but these errors were encountered: