search

PowerShell / vscode-powershell

Provides PowerShell language and debugging support for Visual Studio Code
https://marketplace.visualstudio.com/items/ms-vscode.PowerShell
MIT License
1.69k stars 481 forks source link

Breakpoints not cleaned up if Debug Interactive Session is stopped. #2371

Open JustinGrote opened 4 years ago

JustinGrote commented 4 years ago

Issue Description

If the Interactive Debugger is started, then a breakpoint is set, but then the Interactive Debugger is then stopped, the breakpoints are still present and are not synced with the breakpoint activity bar. Further runs will still trigger debug mode even if the system currently isn't in the interactive debugger.

If PSBreakpoints are cleared when the debugger stops, this should fix it. This may be a PSES issue.

Capture

Attached Logs

Follow the instructions in the README about capturing and sending logs.

Environment Information

Visual Studio Code

Name Version
Operating System Windows_NT x64 10.0.19041
VSCode 1.42.0-insider
PowerShell Extension Version 2019.12.0

PowerShell Information

Name Value
PSVersion 5.1.19041.1
PSEdition Desktop
PSCompatibleVersions 1.0 2.0 3.0 4.0 5.0 5.1.19041.1
BuildVersion 10.0.19041.1
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| |---|---|---| |better-align|wwm|1.1.6| |better-comments|aaron-bond|2.0.5| |better-powershell-syntax-highlighting|justin-grote|0.0.2| |bracket-pair-colorizer-2|CoenraadS|0.0.29| |code-settings-sync|Shan|3.4.3| |gc-excelviewer|GrapeCity|2.1.32| |gistfs|vsls-contrib|0.0.21| |git-graph|mhutchie|1.19.1| |gitlens|eamodio|10.2.0| |indent-rainbow|oderwat|7.4.0| |markdown-all-in-one|yzhang|2.6.1| |powershell-preview|ms-vscode|2019.12.0| |remote-containers|ms-vscode-remote|0.95.0| |remote-ssh-edit-nightly|ms-vscode-remote|2019.12.24000| |remote-ssh-nightly|ms-vscode-remote|2019.12.24000| |remote-wsl|ms-vscode-remote|0.41.6| |todo-tree|Gruntfuggly|0.0.162| |vscode-icons|vscode-icons-team|9.6.0| |vscode-peacock|johnpapa|3.2.0| |vscode-sort-json|richie5um2|1.18.0| |vscode-zipexplorer|slevesque|0.3.1|
TylerLeonhardt commented 4 years ago

So this is a hard one because VS Code only gives us breakpoint gutter events "while debugging". That's why the Interactive Session exists. I opened a SO question to see if there's some mechanism that we can use to support this, but I think our hands are tied, unfortunately:

This is also related https://github.com/PowerShell/PowerShellEditorServices/issues/1091 but kinda the opposite ask.

JustinGrote commented 4 years ago

So is it not possible to just clear all the breakpoints in the PSES powershell instance on the "stop debugging" event? That will fix the problem.

EDIT: To be clear, clear the breakpoints within PSES but not remove them in VSCode. Then the next time the debugger starts it will just reassign them based on what is currently set in VSCode. Basically this is a PSES post-debug cleanup item, even if the debug ends "unexpectedly" e.g. stop is pressed in Interactive Mode.

TylerLeonhardt commented 4 years ago

I suppose we could do that. The question is really what the expected behavior is... and how do we want to confuse the user given the limitation of VS Code.

If we clear all the breakpoints when the debugger is stopped, a user might run a script (or command from a module) directly in the PSIC that has a breakpoint set in it (clearly looking at the editor) and expect that breakpoint to be hit and the debugger to kick in.

JustinGrote commented 4 years ago

That would still work though wouldn't it? It would get set at time of run. Also if you set breakpoints prior to starting a debug run in PSES, whatever is in vscode would just be additive.

Seems like a hard edge case for default behavior, whereas the way it behaves now affects me every single day.

On Thu, Dec 19, 2019, 3:26 PM Tyler James Leonhardt < notifications@github.com> wrote:

I suppose we could do that. The question is really what the expected behavior is... and how do we want to confuse the user given the limitation of VS Code.

If we clear all the breakpoints when the debugger is stopped, a user might run a script (or command from a module) directly in the PSIC that has a breakpoint set in it (clearly looking at the editor) and expect that breakpoint to be hit and the debugger to kick in.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/PowerShell/vscode-powershell/issues/2371?email_source=notifications&email_token=ADUNKUQUTDRNHGQSQWOIHCLQZP7JNA5CNFSM4J4CF3K2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHLMBQQ#issuecomment-567722178, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUNKUTUBTKUEUGYLXD57L3QZP7JNANCNFSM4J4CF3KQ .

JustinGrote commented 4 years ago

Basically, my recommendation would be:

  1. Add a configurable option "powershell.removeBreakpointsOnStop"
  2. If configured, whenever a stop debug is triggered, send a "Get-PSBreakpoint | Remove-PSBreakpoint" to PSES.

(Sorry for the pseudo-language, I'm not great at typescript and haven't tried to delve into the actual code)

JustinGrote commented 4 years ago

@rjmholt @TylerLeonhardt

An alternative thought, is it possible for the extension on a pause to "re-poll" the breakpoints? That way if you had an interruption and start again, the breakpoint list would refresh and you could clean them up at that time.

SydneyhSmith commented 4 years ago

@JustinGrote that could be an interesting idea, let's reengage on this after our next release