Auto Variables tab not populating since last update, also breakpoints ghosting

[kirilan]

System Details

• Operating system name and version: Windows 10 (1607)
• VS Code version: 1.10.2
• PowerShell extension version: 0.11.0
• Output from $PSVersionTable:
  Name Value

---

PSVersion 5.1.14393.206
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14393.206
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

Copy / paste the below commands into the PowerShell Integrated Terminal, and paste the output here

code -v
there's no PATH to code.exe, still it does nothing 
$pseditor.EditorServicesVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
0      11     0      0
code --list-extensions --show-versions
$PSVersionTable
Name                           Value
----                           -----
PSVersion                      5.1.14393.206
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14393.206
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Issue Description

debug Variables window under watcher is not populating, when a breakpoint is hit
the only thing that is showing there is $__psEditorServices_CallStack

in addition once you clear the break points and run the debugger using (current file) option it still breaks on the same breakpoints even though they are cleared.

Attached Logs

1490359376-d56af262-7155-4476-8182-b6bcffeff9111490359374739.zip

Follow the instructions in the [README](https://github.com/PowerShell/vscode-powershell#reporting-problems
1490359376-d56af262-7155-4476-8182-b6bcffeff9111490359374739.zip
)
about capturing and sending logs.

[briansimoni]

I am having the same problem with a similar system configuration.

[daviwil]

Thanks for the pointers, I'll take a look for next week's patch update.

[daviwil]

Hey @rkeithhill, do you mind looking into this one?

[rkeithhill]

Can do. Hmm, looks like this changed with 0.11.0 contrary to the OP version info. In 0.10.2 it was working correctly. And in fact, the logs don't lie - PowerShell Editor Services Host v0.11.0.0 starting. :-) Do you have any ideas/hints based on what was changed for 0.11.0?

[daviwil]

Nah, I didn't touch the variable path. I did touch the path where watch variables are resolved (the EvaluateRequest) but I only changed the behavior when you are typing a command into the Debug Console. Who knows though, I could have broken something else that lead to this.

[rkeithhill]

I was wrong. This bug is in 0.10.x. But is mitigated if you break inside a function. There are several issues going on here. First there were some issues with the conversion of the AddToAutoVariables method in DebugService when we had to use PSObject instead of PSVariable. Although one issue was latent in the original code (go figure - when you test for Flags enum you need to use bitwise & instead of |). Anyway, there were a few other issues testing against PSObject TypeNames instead of comparing types directly. Those are fixed and expect a PSES PR soon.

However there is a bigger issue here that deals with the debugger now dot sourcing scripts into the global session in the Integrated Console. The effectively brings all script level variables into the global session. Also, the current code assumes that scope 0 is never global which is not true anymore. So now, with the previous issues fixed, all the globals wind up showing up in Auto and all Script variables are in Global because of the dot sourcing. . :-(

[daviwil]

Yeah, that's a little unfortunate and might be confusing to the user. Maybe there's some way we can take a snapshot of the variables in the session just before dot sourcing the debugged script the first time so that we can keep track of which new variables might have been added by running the script?

[rkeithhill]

Are we sure we want to always dot source the debugged script? Yeah, I get that ISE did it that way but it doesn't necessarily make it the best way. For instance, this can lead to scripts where setting a global variable without the $global: prefix will work during debug but not during normal execution. This debug feature effectively removes Script scope - at least for the initial script.

That's a significant behavior change between debug and normal execution. I'd prefer a safe debug environment that allows folks to dot source if they want to. And users can already dot source script into the IC w/F8. Perhaps we could make this a debug configuration option - "dotSourceScript": false/true?

RE snapshot of variables - you would want to show a script scope variable that normally shadows a global variable but in this scheme you wouldn't show that variable in Auto because the name matches a predefined global. Although that is admittedly a corner-case scenario.

The other problem I have with PS debugging is determining which scope the top stack frame corresponds to. Get-Variable has s Scope parameter that takes either Global, Script, Local or a number (stack frame depth). So getting the Script and Globals are easy. Then we walk each stack frame and get the variables for that stack frame (-Scope frameDepth). So checking to see if stack frame 0 is global scope can only be determined (I think) by seeing if the total callstack size is 1. That will probably work but I hate relying on such a hack. :-(

[SeeminglyScience]

So checking to see if stack frame 0 is global scope can only be determined (I think) by seeing if the total callstack size is 1. That will probably work but I hate relying on such a hack. :-(

Another option is checking if the GlobalScope and CurrentScope properties of SessionStateInternal match. That would be more reflection though.

[rkeithhill]

snapshot of the variables in the session

@daviwil Where is the best place to do that? In the DebugService ctor?

[daviwil]

Before trying any further magic to make globals not show up in Auto, let's talk about another approach:

1. Maybe the launch config should have an option that determine whether their script is dot-sourced into the session, disabled by default?
2. Maybe globals showing up in Auto should be the expected behavior when the user chooses to dot-source their debugged script into the session?

What do you think? Making the dot-sourcing behavior an option will cause some confusion in 0.12.0 but so long as we make it clear that there's an option to control the behavior now I think it should be fine.

[rkeithhill]

That seems like a reasonable approach. One question is what should the default be? I'd vote for not dot-sourced by default but that's just one vote. :-)

[daviwil]

Yep, I was thinking it should be turned off by default. The more disruptive behavior should be opt-in.