vscode-powershell: Debugger frozen after first breakpoint
System Details
- Operating system name and version: macOS 10.12.6
- VS Code version: 1.14.2
- PowerShell extension version: 1.14.1
- Output from
$PSVersionTable:
1.14.2
cb82febafda0c8c199b9201ad274e25d9a76874e
Angular.ng-template@0.1.4
CoenraadS.bracket-pair-colorizer@0.10.8
PeterJausovec.vscode-docker@0.0.16
Shan.code-settings-sync@2.8.2
abusaidm.html-snippets@0.1.0
adamvoss.yaml@0.0.7
christian-kohler.path-intellisense@1.4.2
dbaeumer.vscode-eslint@1.2.11
donjayamanne.python@0.7.0
ecmel.vscode-html-css@0.1.7
eg2.tslint@0.17.0
emmanuelbeziat.vscode-great-icons@2.1.13
esbenp.prettier-vscode@0.22.1
howardzuo.vscode-npm-dependency@1.1.4
ms-mssql.mssql@1.1.0
ms-vscode.Theme-1337@0.1.4
ms-vscode.csharp@1.11.0
ms-vscode.PowerShell@1.4.1
natewallace.angular2-inline@0.0.17
robertohuertasm.vscode-icons@7.12.0
Name Value
---- -----
PSVersion 6.0.0-beta
PSEdition Core
GitCommitId v6.0.0-beta.5
OS Darwin 16.7.0 Darwin Kernel Version 16.7.0: T...
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Reproduce
- Set breakpoint anywhere in the script.
- Run ‘PowerShell Launch Current File’
- Once breakpoint has been hit, click Continue or Step In.
Issue Description
I cannot use the debugger in VS Code as expected. Once I try to step into a breakpoint or continue running a script, the debugging process appears to freeze. There are no visible errors and I can continue navigating and using VS Code. To continue and reproduce the issue, again, I have to stop the debugging process and restart the console.
Additionally, I’ve gone through and removed the extension, tried the latest insider build of VS Code and rolled back to PowerShell 6 Beta 3 and 4.
Attached Logs
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 19 (4 by maintainers)
Tried that out, didn’t work great unsurprisingly.
The only way I was able to fix this was by pulling out the little bit of native code corefx uses and working that into a implementation similar to yours @rkeithhill. It appears to work great, but a discussion needs to be had about how it should be integrated. I can think of three options.
Merge it as is. I don’t really like this option because it complicates what is currently a very approachable build process. This would also probably add some extra manual steps to the release process, because the native code can only be built on Unix and the net452 assemblies can only be built on Windows. Not to mention adding native code to the scope of the project.
Create a separate project/package for the tiny bit of code to turn off input echo.
Wait for corefx to add a
ReadKeyAsyncmethod (or similar). Honestly, this is probably the best choice.Here’s the branch with the current progress.
Version 1.16.1 suddenly stopped working. Have noticed that sometimes it will eventually (like up to 30 seconds) step to next line, but even as poor a coder as i am i dont need that long to read a line of code!
Reinstall worked on my work desktop which isnt Anniversay edition so im thinking it might be related to PS5.1?
@SeeminglyScience I like option 2 as well. Hopefully option 3 comes to pass but who knows how long that will take. We can’t afford to wait - folks are getting pretty upset about this. And if option 3 does happen, then the changes to PSES would be minimized vs option 1.
The last time I asked them for this they didn’t seem very interested, hopefully it’s different this time.
I agree with Patricks approach #2, creating a small helper library that doesn’t need to get recompiled with PSES. If we could make it work then we only need to compile/sign/ship it once and then use it in future PSES releases until corefx gains a ReadKeyAsync API.
Very nice work, @SeeminglyScience, you rock!
@SeeminglyScience Looks like @rkeithhill opened an issue about your 3rd choice a little over a month ago https://github.com/dotnet/corefx/issues/25036 - maybe it’s worth pinging on that issue to see what they say?