Remote development over SSH introduced bug when upgrading from VS Code 1.51.1 to 1.52.0 #4205
Assignees
Labels
*duplicate
Issue identified as a duplicate of another issue(s)
Comments
|
Which services are you running? Is there any process using lots of CPU or memory on the remote? |
|
I have about 12 Scala services running for my company's development environment. These services use a lot of CPU on the Linux machine when spinning up (takes about 1 minute). Once they're spun up, they're using ~20-30% of CPU and a very minimal amount of memory, but VS Code still hangs on the host Mac (no matter how much time I give it). The Linux machine itself is not hanging and I can still perform other actions without lag (even when SSH'ing into it from my host). |
|
Can you try with the 1.52.1 we released yesterday, or Insiders? https://code.visualstudio.com/insiders @alexdima any idea why we would be more sensitive to this in 1.52? |
|
Okay, I just tried with both 1.52.1 and Insiders (1.53.0-insider). No luck. Both of those behave exactly the same as described in the original post for 1.52.0. As a bit of clarification to my original post where I'd included 5 lines of logs that keep repeating...that repeating only happens when the services are running on my remote machine. I don't get repeating logs like that if my services aren't running. So maybe there's an issue deep down with the connection not staying open? Thanks for your help thus far. |
|
Could you try setting this |
|
That was actually one of the first settings I changed while troubleshooting. See second bullet point under |
|
@chloehale Could you please share with us the server logs? I think you can find them on the remote machine at |
|
I do not see any files under the name Log (Remote Server) in VS Code's output panel Remote - SSH log in VS Code's output panel |
|
This might be caused by our new automatic port forwarding feature which scans the remote OS for available ports in order to forward them locally (microsoft/vscode#112843) |
|
@chloehale would you be willing to try the following steps? This would help us confirm that we've found the issue, and you'll also get to use a more up-to-date version.
Setting that environment variable will cause VS Code (insiders only right now, I'll make a proper fix that doesn't involve an environment variable for the next stable release), to not do the proc filesystem reading that we do to automatically forward ports for you. This does mean that automatic port forwarding will not work while you have that environment variable set. |
|
I just followed your steps and am unable to reproduce the hang/lag issue. It appears to have worked! Maybe you've already included the fix in the Insiders version that I downloaded ~20 minutes ago, but I thought I'd mention that (oddly) I'm now unable to reproduce my issue with the Insiders version at all...even if I set |
|
Thanks for trying it out! We haven't added a more permanent fix yet, but maybe the issue is just transient. A more permanent fix will come in January, when we start releasing insiders every day again. |
|
Hi there, I'm seeing something similar in BetterThanTomorrow/calva#869 (comment). For convenience, I'll paste the relevant comments here: BetterThanTomorrow/calva#869 (comment) I can confirm that going back to VS Code 1.51 (October version) as instructed in https://stackoverflow.com/questions/49346733/how-to-downgrade-vscode makes editing fast again. BetterThanTomorrow/calva#869 (comment) Heya, I think I spoke too soon. I can see the slowness happen again, but I don't think this is inherently related to Calva - it's just that calvafmt might be a bit demanding on the CPU when editing. Let me explain a bit better. My setup is Calva while running a Shadow CLJS build, and I am not using a repl connection to Calva. When using VSCode 1.51.1, task manager shows WSL as using 0-2% CPU. But when using VSCode 15.2.1, there's a constant 12-19% CPU usage. If I turn off the Shadow CLJS server or close VSCode, this drops to 0-2%. #4205 details similar slowness with the Remote WSL extention on the same version change. If I follow the steps in #4205 (comment), I get a 0-2% CPU usage at rest. But if I remove that var, I see a 15%-20% CPU usage. So I think what's happening here is that the VSCode remote extension is not playing well with Shadow CLJS. |
|
Python unit tests done over Remote SSH also show a bunch of ports in the range 30000-40000 that start showing up in the Ports view as of late. I wrote this up in #4274. And auto port forwarding from processes I deliberately launch in the terminal that I want to forward, don't forward. I imagine the underlying cause could be similar. I'm not having any performance issues otherwise though. Just the ports issue. |
|
Just adding another data point - I had this same problem. Everything worked fine in 1.51.1, but the problem began in 1.52.0 and remained in 1.52.1. When I ran a web service that used ports in the 8000's range, VSCode stopped working. The fix mentioned above also worked for me -
|
|
Thanks for the additional data point! If you're on the latest insiders, then |
alexr00
added
*duplicate
|
I'm commenting on this issue because I've suddenly started seeing this issue! It happens when code starts and tries to open the remote workspace. and the errors I'm seeing: I've tried exporting |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I'm not sure how to narrow down the issue, but the Remote Development extension pack works great with VS Code version 1.51.1 and only sometimes works with VS Code version 1.52.0.
Here's my setup:
Here's what I'm seeing:
Log (Window)over and over again:What I've tried so far (to no avail):
"remote.autoForwardPorts": falsesince I noticed that starting services on my Linux machine caused many more ports to be forwarded."git.enabled": falseand disabled everything I could find related to git to rule git problems out.No matter what I've tried, I can consistently reproduce this issue: no services running = no lag, services running = VS Code hangs. The only thing that I've found to fix it thus far is to go back to using VS Code version 1.51.1.
Is there any information I can provide to help figure out what the root cause is?
The text was updated successfully, but these errors were encountered: