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.

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

Breakpoints cannot be removed when debugger isn't running #625

Closed
Aculeo opened this issue Mar 28, 2017 · 14 comments

Comments

Projects
None yet
8 participants
@Aculeo
Copy link

commented Mar 28, 2017

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:

grafik

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

grafik

Get-PSBreakPoint shows that it still exists:

grafik

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

This comment has been minimized.

Copy link
Collaborator

commented Mar 28, 2017

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

@cielakm

This comment has been minimized.

Copy link

commented Mar 29, 2017

I have the same issue.

@ThePSAdmin

This comment has been minimized.

Copy link

commented Mar 30, 2017

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

This comment has been minimized.

Copy link
Author

commented Mar 31, 2017

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

@daviwil

This comment has been minimized.

Copy link
Collaborator

commented Apr 1, 2017

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!

@daviwil daviwil self-assigned this Apr 1, 2017

@daviwil daviwil added this to the Next Patch Update milestone Apr 1, 2017

@rkeithhill

This comment has been minimized.

Copy link
Collaborator

commented Apr 1, 2017

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

This comment has been minimized.

Copy link

commented Apr 1, 2017

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

@daviwil

This comment has been minimized.

Copy link
Collaborator

commented Apr 1, 2017

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

This comment has been minimized.

Copy link
Collaborator

commented Apr 1, 2017

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

This comment has been minimized.

Copy link
Collaborator

commented Apr 1, 2017

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.

@daviwil daviwil changed the title Cannot remove breakpoint Breakpoints cannot be removed when debugger isn't running Apr 2, 2017

@daviwil daviwil modified the milestones: Next Patch Update, Next Feature Update Apr 6, 2017

@daviwil daviwil modified the milestones: April 2017, May 2017, 1.1.0 May 8, 2017

@daviwil

This comment has been minimized.

Copy link
Collaborator

commented May 17, 2017

Turns out that even if I implement the proper breakpoint sync logic on the server side, VS Code isn't capable of reacting to the BreakpointEvent that would allow me to update the editor's UI once the debugger starts. I'm going to submit a PR to VS Code to make this work then I'll merge the PSES work once VS Code is capable of handling that event correctly.

The VS Code limitation is tracked here: microsoft/vscode#8642

@daviwil daviwil modified the milestones: 1.2.0, 1.1.0 May 17, 2017

@daviwil daviwil modified the milestones: 1.3.0, 1.2.0 May 24, 2017

@daviwil daviwil modified the milestones: 1.3.0, June 2017 Jun 1, 2017

@spacentropy

This comment has been minimized.

Copy link

commented Jun 2, 2017

I have the same issue.

@spaelling

This comment has been minimized.

Copy link

commented Sep 14, 2017

still in 1.43. Is the fix planned for 1.5.1?

@daviwil

This comment has been minimized.

Copy link
Collaborator

commented Sep 14, 2017

Yes, but there's no ETA for when 1.5 or 1.5.1 will be released. The team is busy on some internal compliance work right now so we won't have time to work on larger features or issues for a while.

@daviwil daviwil modified the milestones: 1.5.1, Future Oct 26, 2017

daviwil added a commit to daviwil/PowerShellEditorServices that referenced this issue Oct 26, 2017

Clear existing breakpoints in session when debugger starts
This change ensures that the breakpoints the user has in their runspace
correspond to the list of breakpoints that are enabled in the debug
adapter client.

Resolves PowerShell/vscode-powershell#625

@daviwil daviwil modified the milestones: Future, 1.5.0 Oct 27, 2017

daviwil added a commit to daviwil/PowerShellEditorServices that referenced this issue Oct 27, 2017

Clear existing breakpoints in session when debugger starts
This change ensures that the breakpoints the user has in their runspace
correspond to the list of breakpoints that are enabled in the debug
adapter client.

Resolves PowerShell/vscode-powershell#625
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.