-
Notifications
You must be signed in to change notification settings - Fork 770
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
Pylance latest release killing remote connections to notebooks #4983
Comments
I'm seeing the same issue. Version v2023.10.20 works. |
Thanks. We are able to repro this and are investigating. |
I believe the culprit is this commit: Not sure how that's causing a crash, but I cannot repro the crash with the commit before this and it repros with this commit. |
Okay now I'm not sure. The repro isn't very consistent for me. @deepak1556, is there a way to get the callstack of the crashing node extension host? Hopefully that might tell us what code is causing the crash. |
It seems I also cannot reproduce the crash with 1.81 of VS code (and 2023.10.30 for Pylance). 1.82 is where VS code moved to Electron 25/Node 18.5. My guess is that's the cause of the problem. Javascript code doesn't normally crash Node, so this might be a bug in Electron/Node. |
Oh it seems Deepak is OOF. @rzhao271 do you have any tips on collecting a callstack for when the extension host goes down? I can't reproduce this in 1.81 of VS code, so it might be a Node 18.5 specific problem. |
@rchiodo if you are able to repro with local extension host then https://github.com/microsoft/vscode/wiki/Native-Crash-Issues#creating-a-crash-report would be the way to go. If you want to collect crash dumps for remote extension host then set What are the steps to repro, I can give it a try and get you the callstacks. |
To reproduce do what the original poster said. VS code 1.83 Open a notebook in WSL or SSH. It should crash the extension host pretty easily. |
@rchiodo I was able to repro the issue, however there is no crash involved with remote agent process as well as extension host process (core dumps were not generated). I captured strace output for both these processes and turns out the extension host was killed with
Now the question is why does exiting the python process result in a |
Solution from @luabud works for me |
Solution from @luabud work for me BUT with a pretty trick otherwise as soon as pylance is up, my vscode server crash. What I did :
|
@deepak1556 thanks for the analysis. That gives us greater confidence that the fix is the correct one. I'm not sure how the failure to kill a process in a subprocess is cascading up to the extension host though. And why notebooks have to be involved. I'm going to try creating a simpler repro and I'll log a bug on VS code with it if I can get the same behavior. |
This issue has been fixed in release version 2023.10.40 and prerelease version 2023.10.41, which we've just released. You can find the changelog here: CHANGELOG.md |
@rchiodo, assuming that #4982 is a dupe, this user says that they're seeing it without using notebooks -- #4982 (comment) |
If the crash happens before the Pylance extension gets a chance to be automatically updated to 2023.10.40 (pr 2023.10.41), there are two workarounds:
|
Unfortunately, I can't seem to get a simple repro to cause the same problem. The child is just killed. It doesn't cause any ripple effects. My attempt at a simpler repro was here: |
I was facing this issue, and can confirm that upgrading to the 2023.10.41 pre-release version solves it. Thank you! |
Yes, good point! And here's how to do this same thing when using Remote-SSH: microsoft/vscode#195617 (comment)
|
Most importantly, see multiple other reports of this issue over at:
Downgrading the pylance extension seems to fix that issue for most people.
Environment data
ms-python.python@2023.19.12921011
ms-python.vscode-pylance@2023.10.31
(more environment info related to this here: #4986
Code Snippet
NA
Repro Steps
Expected behavior
Able to work with that notebook
Actual behavior
Remote window disconnects and fails to reload.
Downgrading pylance to
v2023.10.20
on remote fixes this.I was able to downgrade, select a kernel, upgrade, and have that specific notebook work. Opening a new notebook would then kill the connection.
Logs
output
The text was updated successfully, but these errors were encountered: