Repository navigation
The debugger should not be disabled when you remove the last breakpoint if you are currently stepping through the debugger #9824
Description
The Remove-PSBreakpoint command has logic that disables the debugger when the last breakpoint is removed. As defined, this can happen even if you are currently stepping through the debugger, such that any subsequent step command (step into, step over, step out) is ignored and the script runs to completion.
The condition needs to also check to make sure that you are not currently stepping through the debugger. If you are, the debugger must not be disabled.
This issue is being fixed as part of PR #9825. I am simply adding it here for tracking purposes.
Steps to reproduce
& {
$bp = Set-PSBreakpoint -Command Remove-PSBreakpoint
Remove-PSBreakpoint -Breakpoint $bp
}
1 + 1Expected behavior
Regardless of whether you use stepInto, stepOver, or stepOut, you should be able to step to the 1 + 1 command.
Actual behavior
You cannot step to the 1 + 1 command.
Environment data
Name Value
---- -----
PSVersion 6.2.0
PSEdition Core
GitCommitId 6.2.0
OS Microsoft Windows 10.0.17763
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Activity
lzybkr commentedon Jun 5, 2019
When debugging is enabled, there is a significant impact to performance. It seems like a bad idea to degrade performance for the rest of the session if the debugger isn't actively needed.
KirkMunro commentedon Jun 5, 2019
Jason Shirk (@lzybkr) I understand that and figured that was the reasoning behind this code; however, without this fixed, if I'm in a debug session, on the last breakpoint, and I remove that breakpoint and then step, the code runs to the end because the debugger is disabled. How can the debugger no longer be needed when I'm in the debugger stepping through code?
If we want this logic needs to be kept, then the condition needs to change so that the debugger is not disabled the last breakpoint is removed and if you are currently in the debugger. I'm not sure what flag/setting tells me that, but there must be one. I'll have a look to see.
[-]The debugger should not be disabled when you remove the last breakpoint[/-][+]The debugger should not be disabled when you remove the last breakpoint if you are currently stepping through the debugger[/+]KirkMunro commentedon Jun 5, 2019
Thanks for the comment Jason Shirk (@lzybkr). I put the disabling logic back, with added conditional checks to ensure that you are not currently stepping in the debugger. If you are, the debugger will not be disabled.
lzybkr commentedon Jun 5, 2019
That's better, but still not optimal. The debugger should also be disabled when you go (no more breakpoints could be hit) and when you've exited all scripts (empty callstack).
KirkMunro commentedon Jun 5, 2019
I don't disagree, but those two additional scenarios don't have anything to do with Remove-PSBreakpoint though, do they? I mean, when you
continueand no more breakpoints can be hit, it's still disabled (because Remove-PSBreakpoint looks at the current debugger command if there is one, and only prevents the disabling of the debugger if it was a step command. And for when you've exited all scripts, I would presume that the debugger is already being disabled, but I haven't looked at that code.microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.