Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[Powershell Preview regression bug] Debugger hangs when a breakpoint inside a scriptblock is hit #2448

Closed
Jawz84 opened this issue Jan 29, 2020 · 14 comments
Closed

[Powershell Preview regression bug] Debugger hangs when a breakpoint inside a scriptblock is hit #2448

Jawz84 opened this issue Jan 29, 2020 · 14 comments
Labels
Area-Debugging Issue-Bug A bug to squash. Resolution-Fixed Will close automatically.
Milestone
Consider-vNext

Comments

@Jawz84
Copy link

Jawz84 commented Jan 29, 2020 •
edited
Loading

Issue Description

I am experiencing a problem with the debugger. It hangs when a breakpoint inside a scriptblock is hit.

Steps to reproduce:

  • Paste the script as a new ps1 file, and run it.
  • In the Integrated terminal type 'Stop-Service -Name <tab>'
  • The debug session is started, but it does not accept further interaction.
$s = {
    param($commandName, $parameterName, $wordToComplete, $commandAst, $fakeBoundParameters)
    Set-PSBreakpoint -command Get-Service
    $services = Get-Service | Where-Object {$_.Status -eq "Running" -and $_.Name -like "$wordToComplete*"}
    $services | ForEach-Object {
        New-Object -Type System.Management.Automation.CompletionResult -ArgumentList $_.Name,
            $_.Name,
            "ParameterValue",
            $_.Name
    }
}
Register-ArgumentCompleter -CommandName Stop-Service -ParameterName Name -ScriptBlock $s

Beyond this point, you can only kill the integrated terminal. It will not accept any other input.
image

NOTE:
This only happens in the PowerShell Preview Extension. The GA PowerShell extension does not have this bug.

The bug is also not reproducible in a stand alone console in PowerShell 5.1, Powershell 6.2.3, or 7.0.0.rc2, or PowerShell_ise (5.1). It is specific to the Preview version of the extension.

Attached Logs

1580281742-dc8c91be-e55c-4eed-822f-c087bed38b011580281219461.zip

Environment Information

Visual Studio Code

Name Version
Operating System Windows_NT x64 10.0.18363
VSCode 1.41.1
PowerShell Extension Version 2020.1.0

PowerShell Information

Name Value
PSVersion 7.0.0-rc.2
PSEdition Core
GitCommitId 7.0.0-rc.2
OS Microsoft Windows 10.0.18363
Platform Win32NT
PSCompatibleVersions 1.0 2.0 3.0 4.0 5.0 5.1.10032.0 6.0.0 6.1.0 6.2.0 7.0.0-rc.2
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

Visual Studio Code Extensions

Visual Studio Code Extensions(Click to Expand)
Extension Author Version
azure-account ms-vscode 0.8.8
azure-pipelines ms-azure-devops 1.165.1
azurecli ms-vscode 0.4.6
bracket-pair-colorizer-2 CoenraadS 0.0.29
cmake twxs 0.0.17
code-settings-sync Shan 3.4.3
cpptools ms-vscode 0.26.3
csharp ms-vscode 1.21.9
csharpfixformat Leopotam 0.0.84
docomment k--kato 0.1.8
gitlab-ci-validator cstuder 1.0.0
gitlens eamodio 10.2.0
Go ms-vscode 0.12.0
LiveServer ritwickdey 5.6.1
powershell-preview ms-vscode 2020.1.0
python ms-python 2020.1.58038
remote-containers ms-vscode-remote 0.94.0
remote-ssh ms-vscode-remote 0.48.0
remote-ssh-edit ms-vscode-remote 0.48.0
remote-wsl ms-vscode-remote 0.41.7
swagger-viewer Arjun 2.2.2
terraform mauve 1.4.0
vscode-azurefunctions ms-azuretools 0.20.2
vscode-azureterraform ms-azuretools 0.3.0
vscode-icons vscode-icons-team 9.7.0
vscode-markdownlint DavidAnson 0.33.0
vscode-pull-request-github GitHub 0.14.0
vscode-remote-extensionpack ms-vscode-remote 0.19.0
vscode-svg-previewer vitaliymaz 0.5.1
vscode-typescript-tslint-plugin ms-vscode 1.2.3
vsliveshare ms-vsliveshare 1.0.1510
vsonline ms-vsonline 1.0.1507
xml DotJoshJohnson 2.5.0
@ghost ghost added the Needs: Triage Maintainer attention needed! label Jan 29, 2020
@rjmholt
Copy link
Contributor

rjmholt commented Jan 31, 2020

May be related to #2246.

Worth noting that generally most scriptblocks will behave as normal, but there are a few exacerbating factors here:

  • The scriptblock is used as an argument completer, so it gets called deep within PowerShell via PSReadLine
  • The breakpoint set is a command breakpoint
  • The breakpoint seems to be set within the completer scriptblock itself, creating a new breakpoint each time a completion is asked for

@rjmholt
Copy link
Contributor

rjmholt commented Jan 31, 2020

I've just managed to reproduce this. Will investigate

@rjmholt
Copy link
Contributor

rjmholt commented Feb 1, 2020 •
edited
Loading

So a preliminary look shows the following:

  • The thread moving to resume the debugger is waiting for the frame to exit here
  • The pipeline thread waiting for the current PowerShell execution to complete here (it's where the pipeline thread has hit the breakpoint inside the completer scriptblock)
  • A PowerShell execution thread running the PSReadLine prompt script, which is waiting to acquire the pipeline thread handle

@rjmholt
Copy link
Contributor

rjmholt commented Feb 1, 2020

So:

  • ReadLine is waiting on the completion, which is blocked by the debugger
  • The debugger is waiting on the stack frame to pop, which is blocked by ReadLine

First naive theoretical solution: flag when the command being run is the prompt to tell the debugger not to wait for the stack frame to resume

@SeeminglyScience
Copy link
Collaborator

It's probably going to go further than that. Since PSRL is still running, the ReadLine runspace handle will be taken. That handle queue isn't set up to be nested like the normal execute handles. None of the read line stuff is set up for that scenario iirc.

Plus even if you get all that sorted, the PSEventManager will still be busy processing the original completion call, so once the debugger stop happens, any calls to intellisense or similar will deadlock. Honestly, trying to set it all up as PowerShell events was a mistake on my part. A private contract field that stores a delegate should be added to PSRL that we would use in place of the over complicated OnIdle system.

@SydneyhSmith SydneyhSmith added Area-Debugging Issue-Bug A bug to squash. and removed Needs: Triage Maintainer attention needed! labels Feb 4, 2020
@rjmholt rjmholt removed their assignment Feb 19, 2020
@rjmholt rjmholt mentioned this issue May 21, 2020
Closed
@rjmholt rjmholt mentioned this issue Jul 22, 2020
Merged
6 tasks
@rjmholt rjmholt mentioned this issue Mar 29, 2021
Closed
@andyleejordan andyleejordan added this to the Consider-vNext milestone Sep 22, 2021
@andyleejordan
Copy link
Member

@Jawz84 Hello, and thank you for your patience! The latest PowerShell Preview for VS Code is now out, and includes the reworking of our pipeline and threading architecture in PowerShell/PowerShellEditorServices#1295. Could you verify if this issue still reproduces using v2022.1.0-preview? Please note that this preview is likely to include other bugs, and you should feel free to file new issues for those so we can work through them. Thanks again!

@Jawz84
Copy link
Author

Jawz84 commented Jan 20, 2022 via email

@ghost ghost added the Needs: Maintainer Attention Maintainer attention needed! label Jan 20, 2022
@Jawz84
Copy link
Author

Jawz84 commented Jan 21, 2022

Let me start out by saying: thanks for the huge amount of work, that has undoubtably gone into the complete overhaul. 💙

I've tried to reproduce on 2022.1.0-preview. This time, the behaviour was different. The debugger did attach after the 'tab' keystroke. After that, I was able to F10 step through, until I hit this error on line 11 (closing curly for scriptblock $s): This error is shown in the terminal:

Last 21 Keys:

 s t o p - s e r v i c e Spacebar - n a m e Spacebar Tab Tab

### Exception

System.ObjectDisposedException: Safe handle has been closed.
Object name: 'SafeHandle'.
   at System.Runtime.InteropServices.SafeHandle.InternalRelease(Boolean disposeOrFinalizeOperation)
   at System.Threading.WaitHandle.ObtainSafeWaitHandles(ReadOnlySpan`1 waitHandles, Span`1 safeWaitHandles, Span`1 unsafeWaitHandles)   at System.Threading.WaitHandle.WaitMultiple(ReadOnlySpan`1 waitHandles, Boolean waitAll, Int32 millisecondsTimeout)   at System.Threading.WaitHandle.WaitMultiple(WaitHandle[] waitHandles, Boolean waitAll, Int32 millisecondsTimeout)   at Microsoft.PowerShell.PSConsoleReadLine.ReadKey()
   at Microsoft.PowerShell.PSConsoleReadLine.InputLoop()   at Microsoft.PowerShell.PSConsoleReadLine.ReadLine(Runspace runspace, EngineIntrinsics engineIntrinsics, CancellationToken cancellationToken, Nullable`1 lastRunStatus)

NOTE: the keystrokes recorded here in the terminal are complete, yet they don't reflect the F10 keypresses in the debugger (ofcourse).

After this error, the debugger detaches, and control is given back to the terminal. The terminal is usable as normal after this. VSCode does not hang or become unresponsive. There is one little quirk though: the debug start/stop control is still visible, and showing as if the debugger session is still running:

image

I think it's a major improvement!

@Jawz84
Copy link
Author

Jawz84 commented Jan 21, 2022

I just noticed after posting, that the powershell integrated console had an orange exclamation triangle, and when I hovered over it, this displayed:
image

I've tried to reproduce this after. I haven't yet been able to do so.

@andyleejordan
Copy link
Member

Let me start out by saying: thanks for the huge amount of work, that has undoubtably gone into the complete overhaul. 💙

I've tried to reproduce on 2022.1.0-preview. This time, the behaviour was different. The debugger did attach after the 'tab' keystroke. After that, I was able to F10 step through, until I hit this error on line 11 (closing curly for scriptblock $s): This error is shown in the terminal:

Last 21 Keys:

 s t o p - s e r v i c e Spacebar - n a m e Spacebar Tab Tab

### Exception

System.ObjectDisposedException: Safe handle has been closed.
Object name: 'SafeHandle'.
   at System.Runtime.InteropServices.SafeHandle.InternalRelease(Boolean disposeOrFinalizeOperation)
   at System.Threading.WaitHandle.ObtainSafeWaitHandles(ReadOnlySpan`1 waitHandles, Span`1 safeWaitHandles, Span`1 unsafeWaitHandles)   at System.Threading.WaitHandle.WaitMultiple(ReadOnlySpan`1 waitHandles, Boolean waitAll, Int32 millisecondsTimeout)   at System.Threading.WaitHandle.WaitMultiple(WaitHandle[] waitHandles, Boolean waitAll, Int32 millisecondsTimeout)   at Microsoft.PowerShell.PSConsoleReadLine.ReadKey()
   at Microsoft.PowerShell.PSConsoleReadLine.InputLoop()   at Microsoft.PowerShell.PSConsoleReadLine.ReadLine(Runspace runspace, EngineIntrinsics engineIntrinsics, CancellationToken cancellationToken, Nullable`1 lastRunStatus)

NOTE: the keystrokes recorded here in the terminal are complete, yet they don't reflect the F10 keypresses in the debugger (ofcourse).

After this error, the debugger detaches, and control is given back to the terminal. The terminal is usable as normal after this. VSCode does not hang or become unresponsive. There is one little quirk though: the debug start/stop control is still visible, and showing as if the debugger session is still running:

image

I think it's a major improvement!

This is super helpful because it looks just like #3751. Given that, I'm going to mark this particular issue as resolved, and thank you for the second repro of that early safe handle disposal bug (which is already triaged and slated to be fixed). Thank you!

@andyleejordan andyleejordan added Resolution-Fixed Will close automatically. and removed Needs: Maintainer Attention Maintainer attention needed! labels Jan 21, 2022
@andyleejordan
Copy link
Member

I just noticed after posting, that the powershell integrated console had an orange exclamation triangle, and when I hovered over it, this displayed: image

I've tried to reproduce this after. I haven't yet been able to do so.

HAHA I have seen that exactly once as well and never been able to repro. It doesn't seem to break anything, and I don't know why it's happening because that environment variable isn't something we touch.

@JustinGrote
Copy link
Collaborator

I've seen it several times but haven't figured out a good repro either.

@ghost ghost added the Needs: Maintainer Attention Maintainer attention needed! label Jan 22, 2022
@andyleejordan andyleejordan removed the Needs: Maintainer Attention Maintainer attention needed! label Jan 22, 2022
@ghost ghost closed this as completed Jan 22, 2022
@ghost
Copy link

ghost commented Jan 22, 2022

This issue has been marked as fixed. It has been automatically closed for housekeeping purposes.

@Jawz84
Copy link
Author

Jawz84 commented Jan 22, 2022

Agreed, thanks. Great work everyone!

@ghost ghost added the Needs: Maintainer Attention Maintainer attention needed! label Jan 22, 2022
@andyleejordan andyleejordan removed the Needs: Maintainer Attention Maintainer attention needed! label Mar 15, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Area-Debugging Issue-Bug A bug to squash. Resolution-Fixed Will close automatically.
Projects
None yet
Milestone
Consider-vNext
Development

No branches or pull requests
6 participants
@andyleejordan @rjmholt @JustinGrote @SeeminglyScience @Jawz84 @SydneyhSmith