Debug Session not respecting Added or removed Breakpoints & Integrated Shell Crash

[GABeech]

Issue Description

When I run a debug session two things happen:

1. Any addition or removal of breakpoints is not respected
2. The Integrated shell Crashes after not exiting correctly

You can replicate this by running a small script like:

while ($true)
{
  Write-Output "I'm In a loop"
  Start-Sleep 10
  Write-Output "I just woke up"
}

Removing Breakpoint

• Set a breakpoint on the first Write-Output
• Debug The script
• Remove Breakpoint on First Write-Output
• Continue running

What will happen is the debugger will break again on the first Write-Output and you won't be able to continue. If you stop execution and type exit in the debug terminal the integrated terminal will crash

Adding Breakpoint

• Debug the script
• Set a breakpoint anywhere in the while loop
• It will never be hit.

Attached Logs

EditorServices.log
vscode-powershell.log

) about
capturing and sending logs.

Environment Information

Visual Studio Code

Name	Version
Operating System	Windows_NT x64 10.0.16299
VSCode	1.26.1
PowerShell Extension Version	1.8.3

PowerShell Information

Name	Value
PSVersion	5.1.16299.492
PSEdition	Desktop
PSCompatibleVersions	1.0 2.0 3.0 4.0 5.0 5.1.16299.492
BuildVersion	10.0.16299.492
CLRVersion	4.0.30319.42000
WSManStackVersion	3.0
PSRemotingProtocolVersion	2.3
SerializationVersion	1.1.0.1

Visual Studio Code Extensions

Visual Studio Code Extensions(Click to Expand)

Extension	Author	Version
aspnet-helper	schneiderpat	0.6.4
ecdc	mitchdenny	0.12.0
EditorConfig	EditorConfig	0.12.4
github-issues-prs	ms-vscode	0.9.0
gitlens	eamodio	8.5.6
jenkins-declarative-support	jmMeessen	0.1.0
markdown-all-in-one	yzhang	1.6.0
PowerShell	ms-vscode	1.8.3
python	ms-python	2018.7.1
rainbow-csv	mechatroner	0.4.2
vscode-github	KnisterPeter	0.30.0
vscode-icons	robertohuertasm	7.25.0
vscode-markdownlint	DavidAnson	0.20.0
vscode-mermaid-preview	vstirbu	0.10.1
xml	DotJoshJohnson	2.3.2

[rjmholt]

Thanks for opening an issue @GABeech. I can reproduce this on my machine. I've been looking into it but haven't found the cause yet. Will continue investigating.

[rjmholt]

So I've debugged this a couple of times and I've just hit a nasty hang here:
https://github.com/PowerShell/PowerShellEditorServices/blob/f1ab46289904b77fe5f5bd97cc89e2f5286444db/src/PowerShellEditorServices/Session/PowerShellContext.cs#L352-L355

[SeeminglyScience]

@rjmholt If you have the PSRL build still, see if you can reproduce it there. I made a lot of changes around the runspace handle queues.

[rjmholt]

So I did some more investigating on this today.

The breakpoint is set correctly and unset correctly, but trying to set it again does nothing at all. This is almost certainly because PSES is being blocked by the current execution.

I was curious as to where PSES thought it was, so I paused the PSES .NET debugger and on my Windows machine in 1.9.1, it reports itself as being here:
https://github.com/PowerShell/PowerShellEditorServices/blob/f1ab46289904b77fe5f5bd97cc89e2f5286444db/src/PowerShellEditorServices/Console/WindowsConsoleOperations.cs#L22

In v2, I think it reports itself as being here:
https://github.com/PowerShell/PowerShellEditorServices/blob/67af23203c0d7aac52a6c5655d7d7f1202e80dd0/src/PowerShellEditorServices/Session/PowerShellContext.cs#L651

I think it basically comes down to the debug adapter not being able to interrupt the script to add a new breakpoint -- which is obviously a problem.

In 1.9.1 I get no crash (or at least I didn't this time). But with v2 I got a pipe broken error, which I think we've seen can also occur in 1.9.1.

[rjmholt]

After looking into this and thinking about it a bit, this looks like a deeper issue -- I'll see what we can do to fix it, but I think we will need to do some cleverness with interrupting the execution of the PowerShell pipeline.

[SeeminglyScience]

We could implement this in 2.0. Taking over script execution between sequence points can be done with events, but that requires all the nested context work done for PSReadLine.

[rjmholt]

If we can engineer that, it would be useful in a whole bunch of cases for cancellation of the PowerShell executions powering most requests -- so we could finally implement $/cancelRequest properly.