Breakpoints cannot be removed when debugger isn't running

[Aculeo]

System Details

• Operating system name and version: Windows 7 Enterprise (x64)
• VS Code version: 1.10.2
• PowerShell extension version: 0.11.0
• Output from $PSVersionTable:

Name                           Value
----                           -----
PSVersion                      4.0
WSManStackVersion              3.0
SerializationVersion           1.1.0.1
CLRVersion                     4.0.30319.42000
BuildVersion                   6.3.9600.17400
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion      2.2

Issue Description

Somehow I still hit breakpoints even after I remove them and start debugging again.

For reproducing, I add a simple breakpoint:

Then I stop debugging, remove the breakpoint by clicking the red circle, and I start debugging again. I still hit the breakpoint:

Get-PSBreakPoint shows that it still exists:

Logs don't seem to contain any useful information, but if helpful I'll turn on verbose logging and attach those. Update: Log when repeating steps

[daviwil]

Yep, you'll need verbose logs on to see anything useful.

[marekciel]

I have the same issue.

[ThePSAdmin]

I have the same issue, and it looks like some kind of caching issue with the interactive console.

As well as breakpoints still being hit, even after being removed, I also experience problems with edits to other files not being registered in the debugger. Maybe easier to explain what I've done.

I have a module project I'm working on, and I create a new pester test for a new function. that checks to see if the command exists, I run the test through the Invoke-Pester launch spec:
"type": "PowerShell", "request": "launch", "name": "PowerShell Pester Tests", "script": "Invoke-Pester", "args": [], "cwd": "${workspaceRoot}"
and the pester test fails (as it should).
So I create a new file (I'm using the ModuleRoot/public directory structure for my functions) and create an empty function in it, save the file and re-run the invoke-pester debug launch command, and the test still fails. However, if I run the pester test task runner, the pester test succeeds. And now, if I restart vscode, or restart the integrated terminal, all the tests via the debug command now work.

I also noticed a few days back, that I wrote a failing test for a new feature in a function, and then implemented that feature in my code and the test carried on failing as above. So I added a breakpoint in my function to see what was happening, and as I stepped through, it jumped over all the new code that I had added. Again, after a restart of vscode, it started working again.

I'm not too keen on attaching the logs here, as it's a work related module I'm working on, but I can send them over email if you need them.

[Aculeo]

Here is the logfile after doing the steps I mentioned in the issue description: https://paste.fedoraproject.org/paste/eSQSvfw~dM644dZXcIJnPV5M1UNdIGYhyRLivL9gydE=/raw

[daviwil]

Good catch! Just reproed this. For now the workaround is that you should only remove breakpoints when the debugger is running. If you remove them when the status bar isn't orange (debugging isn't active), they'll still be there the next time you debug.

This issue is caused by how and when VS Code sends breakpoint information to the PowerShell debugger. Here's what's actually happening:

1. You click a breakpoint in a .ps1 file
2. You press F5
3. VS Code sends me a request to execute your script and tells me that you set a breakpoint in a particular file
4. I run Set-PSBreakpoint to set your breakpoint and then run the script
5. Script execution completes, debug mode ends (no more orange status bar)
6. You click your existing breakpoint to clear it (while the debugger is not running!)
7. You start the debugger again
8. VS Code tells me to launch the script but doesn't tell me anything about breakpoints because it currently doesn't have any active in the UI
9. I run your script in the same runspace which still has the breakpoint registered from the last execution. It gets hit.

So the problem here is that I don't get notified of breakpoint changes when VS Code's debugger isn't running. I only get notified of the user's current breakpoints when the debugger is started again, and only if at least one breakpoint is active.

The ultimate solution is to be more intelligent about breakpoint management on my side. With proper breakpoint state mapping, I can infer which breakpoints have been removed since the last time the debugger was started. This will take a bit of work so it might not come in 0.12.0 this week but potentially in a patch update in the following week.

Sorry for the trouble!

[rkeithhill]

Before we start the debugger, we could clear all breakpoints in the session. That would fix this issue but would be problematic for the (corner) case of someone manually setting a breakpoint at the console. I guess this could be another setting - powershell.integratedConsole.clearAllBreakpointsBeforeDebugging which I would default to true.

[Glober777]

Would it be possible to have a breakpoint created in VSCode once someone sets one within integrated console?

[daviwil]

I don't think we need any extra configuration, we just need to be more aware of the breakpoints that are already set when debugging starts. I've got a design in mind that should make this pretty seamless, I'll give it a shot soon.

Yep, breakpoints set in the console should show up in the VS Code UI, I'll make sure that happens too.

[rkeithhill]

breakpoints set in the console should show up in the VS Code UI

Keep in mind that the VSCode Debug UI doesn't have a "data" breakpoint type yet which is one of the few reasons why you'd want to set a breakpoint in the console.

[rkeithhill]

breakpoints set in the console should show up in the VS Code UI

And breakpoints removed via the console should be removed from the UI as well, right?

How about breakpoints that are modified from the console? I guess that would just look like a set of the same line breakpoint with a different Action script block. And enable/disable-breakpoint from the console should work as well. Yeah, this could be cool.