Repository navigation
2.0.0-insiders-834: prompt gets displayed in an endless loop #1570
Description
Activity
Seems logs didn't make it via drag-and-drop.
1539111398-a60423be-01d3-4cc1-83df-f15ead97e8aa1539111394598.zip
This seems to be the relevant part of the log:
2018-10-09 20:57:11.511 [VERBOSE] C:\projects\PowerShellEditorServices\src\PowerShellEditorServices\Session\PowerShellContext.cs: In method 'ExecuteCommand', line 622: Attempting to execute command(s): [System.Diagnostics.DebuggerHidden()] [System.Diagnostics.DebuggerStepThrough()] param() return [Microsoft.PowerShell.PSConsoleReadLine, Microsoft.PowerShell.PSReadLine2, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null]::ReadLine( $Host.Runspace, $ExecutionContext, $args[0]) System.Threading.CancellationToken 2018-10-09 20:57:11.513 [ERROR] C:\projects\PowerShellEditorServices\src\PowerShellEditorServices\Session\PowerShellContext.cs: In method 'ExecuteCommand', line 692: Execution of the following command(s) completed with errors: [System.Diagnostics.DebuggerHidden()] [System.Diagnostics.DebuggerStepThrough()] param() return [Microsoft.PowerShell.PSConsoleReadLine, Microsoft.PowerShell.PSReadLine2, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null]::ReadLine( $Host.Runspace, $ExecutionContext, $args[0]) System.Threading.CancellationToken Error #1: Exception calling "ReadLine" with "3" argument(s): "The type initializer for 'Microsoft.PowerShell.PSConsoleReadLine' threw an exception." ScriptStackTrace: at <ScriptBlock>, <No file>: line 5 Exception: System.Management.Automation.MethodInvocationException: Exception calling "ReadLine" with "3" argument(s): "The type initializer for 'Microsoft.PowerShell.PSConsoleReadLine' threw an exception." ---> System.TypeInitializationException: The type initializer for 'Microsoft.PowerShell.PSConsoleReadLine' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Microsoft.PowerShell.Keys' threw an exception. ---> System.ArgumentException: An item with the same key has already been added. at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource) at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add) at Microsoft.PowerShell.Keys..cctor() --- End of inner exception stack trace --- at Microsoft.PowerShell.PSConsoleReadLine..cctor() --- End of inner exception stack trace --- at Microsoft.PowerShell.PSConsoleReadLine.ReadLine(Runspace runspace, EngineIntrinsics engineIntrinsics, CancellationToken cancellationToken) at CallSite.Target(Closure , CallSite , Type , Object , Object , Object ) --- End of inner exception stack trace --- at System.Management.Automation.ExceptionHandlingOps.ConvertToMethodInvocationException(Exception exception, Type typeToThrow, String methodName, Int32 numArgs, MemberInfo memberInfo) at CallSite.Target(Closure , CallSite , Type , Object , Object , Object ) at System.Dynamic.UpdateDelegates.UpdateAndExecute4[T0,T1,T2,T3,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3) at System.Management.Automation.Interpreter.DynamicInstruction`5.Run(InterpretedFrame frame) at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)InnerException: System.TypeInitializationException: The type initializer for 'Microsoft.PowerShell.PSConsoleReadLine' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Microsoft.PowerShell.Keys' threw an exception. ---> System.ArgumentException: An item with the same key has already been added. at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource) at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add) at Microsoft.PowerShell.Keys..cctor() --- End of inner exception stack trace --- at Microsoft.PowerShell.PSConsoleReadLine..cctor() --- End of inner exception stack trace --- at Microsoft.PowerShell.PSConsoleReadLine.ReadLine(Runspace runspace, EngineIntrinsics engineIntrinsics, CancellationToken cancellationToken) at CallSite.Target(Closure , CallSite , Type , Object , Object , Object )InnerException: System.TypeInitializationException: The type initializer for 'Microsoft.PowerShell.Keys' threw an exception. ---> System.ArgumentException: An item with the same key has already been added. at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource) at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add) at Microsoft.PowerShell.Keys..cctor() --- End of inner exception stack trace --- at Microsoft.PowerShell.PSConsoleReadLine..cctor()InnerException: System.ArgumentException: An item with the same key has already been added. at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource) at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add) at Microsoft.PowerShell.Keys..cctor()Stéphane BARIZIEN (@sba923) Out of curiosity:
- Does your normal PowerShell session support PSReadLine? I'm assuming Windows PowerShell -- if so, it might be worth installing PowerShell Core to see if its PSReadLine works for you.
- What's your keyboard configuration? Is it US or something else? Normal layout or something like Dvorak or Colemak?
- What's your language/culture set to? en_US, or something else?
Tagging Patrick Meinecke (@SeeminglyScience) as well, since he knows much more about PSReadLine than me
Ah yeah. That's most likely the known issue with different keyboard layouts.
Here's the PR to follow PowerShell/PSReadLine#771The fix has already been merged (Thank you Jason Shirk (@lzybkr)!)
Stéphane BARIZIEN (@sba923) here's the latest preview build for PSReadLine if you'd like to see if that fixes your issue.
Rob Holt (@rjmholt) We should consider updating the insiders build to pull a daily until that fix gets into a beta
Patrick Meinecke (@SeeminglyScience) - wrong PR, the fix was merged in PowerShell/PSReadLine#768
Reacted by Patrick Meinecke and Rob HoltHere's my setup:
- French Windows 10 (preinstalled by Acer)
- English and German language packs installed
- Windows display language set to English
- keyboard layout = French
- Get-Culture returns
LCID Name DisplayName ---- ---- ----------- 1033 en-US English (United States)If I switch VScode to PowerShell Core 6.1, the problem is still present.
If I switch the keyboard layout to English while the PowerShell "integrated terminal" starts, the problem disappears -- even if I later change the keyboard layout back to French.
HTH
Stéphane BARIZIEN (@sba923) - note that some key bindings won't work correctly if you switch keyboard layouts after starting PowerShell - specifically the need for Shift differs between the initial and changed keyboard layouts, e.g. Alt+1 does not require Shift in English, but does for French.
I don't think this affects commonly used key bindings, but it's good to be aware of. If it does affect important bindings, I'd like the hear about it because I rely on a Win32 api that reports incorrect information after the keyboard layout change and the team needs customer feedback to justify fixing it.
Reacted by Rob Holt and Patrick MeineckeStéphane BARIZIEN (@sba923) sorry by "swtich to PSCore", I meant as the standalone app rather than in VSCode. But I think we are using an even newer version of PSReadLine than PSCore anyway.
Anyway, it looks like this is fixed in PSReadLine.
Patrick Meinecke (@SeeminglyScience) maybe we can come up with a way to identify PSReadLine issues similar to how PSReadLine itself deals with them to make crashing and reporting easier? Just thinking about being more helpful to Jason Shirk (@lzybkr) here :)
Rob Holt (@rjmholt) I'm using PowerShell Core 6.1 next to Windows PowerShell 5.1, and don't have any prompt issues in either. Only the integrated terminal in VScode with any post-1.9.0-test-build of the PowerShell extension exhibits the problem.
Jason Shirk (@lzybkr) I find it very strange that 1) there are apps that still do their keycode-to-action-or-character mapping on their own instead of relying on OS infrastructure for that 2) changing the keyboard mapping e.g. with Win+Space while an app is running (which is just... always the case) would cause problems
Where does this all tell about us getting a version of the PowerShell extension for VScode that "just works"? Do you guys have to wait for a fixed PSReadLine to be "baked into" the extension?
Where does this all tell about us getting a version of the PowerShell extension for VScode that "just works"? Do you guys have to wait for a fixed PSReadLine to be "baked into" the extension?
Yeah this issue was just recently discovered and fixed in PSReadLine, so it hasn't made it to a beta release yet. Once that happens we can change the CI build to pull the newest release and it will be a part of the daily build bundle.
Patrick Meinecke (@SeeminglyScience) maybe we can come up with a way to identify PSReadLine issues similar to how PSReadLine itself deals with them to make crashing and reporting easier? Just thinking about being more helpful to Jason Shirk (@lzybkr) here :)
Yeah we need to handle this better, even though a similar situation is unlikely to happen again. Because PSRL is invoked via
PowerShellContext.ExecuteCommandany exceptions are caught, logged, optionally printed to the console, then ignored. If PSRL throws any exception, we should either fall back to old ReadLine or hard fail. Maybe in this case we should log stack trace, OS, framework, and module information into one entry for to make it a little easier to troubleshoot as well.44 remaining items
Not yet, and I must confess I was kinda scared by the first testing reports...
The behaviour's probably going to be better than an infinite loop. There were changes made in the most recent update for international keyboards. But the only way we can improve it is by trying it out.
I've replaced PSRL beta3 with beta4, made it so that Flavien MICHALECZEK (@fMichaleczek)'s workaround is nop-ed out using:
Write-Host ("{0:yyyy-MM-dd HH:mm:ss.fff}: '{1}' starting..." -f (Get-Date), $MyInvocation.MyCommand.Path) $psrl = (Get-Module PSReadLine) if ($null -eq $psrl) { $prerelease = $null Write-Host -ForegroundColor Red ("Cannot find PSReadLine!!!") } else { Write-Host("PSReadLine is '{0}'" -f $psrl.Path) $prerelease = ($psrl | ForEach-Object { $_.PrivateData.PSData })['Prerelease'] } if ($prerelease -eq 'beta4') { Write-Host("No workaround should be needed for PSReadLine 2.0.0 beta4") } else { … }and it seems to work (just did one quick test):
2019-03-29 15:57:11.528: 'C:\private_sba\profile.ps1' exiting. 2019-03-29 15:57:14.411: 'C:\private_sba\NET\DOC\WindowsPowerShell\Microsoft.VSCode_profile.ps1' starting... PSReadLine is 'C:\Users\sba\.vscode\extensions\ms-vscode.powershell-preview-2.0.0\modules\PSReadLine\2.0.0\PSReadLine.psm1' No workaround should be needed for PSReadLine 2.0.0 beta4no endless loop at this point!
I'll deploy this on as many systems as possible and report back.
Reacted by Steve LeeFWIW here's how I checked that I have only copies of PSReadLine beta4 on $env:PSModulePath:
$env:PSModulePath -split ';' | ForEach-Object { $psrlpath = Join-Path -Path $_ -ChildPath 'PSReadLine' $found = Test-Path -LiteralPath $psrlpath $prerelease = $null if ($found) { $isprerelease = $false $psrl = Get-Module -ListAvailable -FullyQualifiedName $psrlpath if ($null -ne $psrl) { $version = $psrl.Version $privatedata = $psrl.PrivateData if ($null -ne $privatedata) { $prerelease = $privatedata['PSData']['Prerelease'] $isprerelease = $true } } [PSCustomObject]@{ Path = $psrlpath Found = $found Version = $version IsPrerelease = $isprerelease Prerelease = $prerelease } } }On one system I'm facing something pretty weird: during execution of Microsoft.VSCode_profile.ps1, and at the TERMINAL prompt, "get-module PSReadLine" returns $null, even though the module is found on $env:PSModulePath.
There must be something I don't understand / guess about the inner workings of PSES / the extension.
Can someone help me out with this?
Same problem on another machine...
Does this give a hint on what's going on?
PS ~/powershell> gmo psreadline PS ~/powershell> import-module -verbose psreadline VERBOSE: Loading module from path 'C:\Users\steph\OneDrive\Documents\WindowsPowerShell\Modules\psreadline\2.0.0\psreadline.psd1'. VERBOSE: Cannot verify the Microsoft .NET Framework version 4.6.1 because it is not included in the list of permitted versions. VERBOSE: Loading 'FormatsToProcess' from path 'C:\Users\steph\OneDrive\Documents\WindowsPowerShell\Modules\psreadline\2.0.0\PSReadLine.format.ps1xml'. VERBOSE: Loading module from path 'C:\Users\steph\OneDrive\Documents\WindowsPowerShell\Modules\psreadline\2.0.0\Microsoft.PowerShell.PSReadLine2.dll'. VERBOSE: Importing cmdlet 'Get-PSReadLineOption'. VERBOSE: Importing cmdlet 'Set-PSReadLineOption'. VERBOSE: Importing cmdlet 'Set-PSReadLineKeyHandler'. VERBOSE: Importing cmdlet 'Get-PSReadLineKeyHandler'. VERBOSE: Importing cmdlet 'Remove-PSReadLineKeyHandler'. VERBOSE: Loading module from path 'C:\Users\steph\OneDrive\Documents\WindowsPowerShell\Modules\psreadline\2.0.0\PSReadLine.psm1'. VERBOSE: Exporting function 'PSConsoleHostReadLine'. VERBOSE: Exporting cmdlet 'Get-PSReadLineOption'. VERBOSE: Exporting cmdlet 'Set-PSReadLineOption'. VERBOSE: Exporting cmdlet 'Set-PSReadLineKeyHandler'. VERBOSE: Exporting cmdlet 'Get-PSReadLineKeyHandler'. VERBOSE: Exporting cmdlet 'Remove-PSReadLineKeyHandler'. VERBOSE: Importing cmdlet 'Get-PSReadLineKeyHandler'. VERBOSE: Importing cmdlet 'Get-PSReadLineOption'. VERBOSE: Importing cmdlet 'Remove-PSReadLineKeyHandler'. VERBOSE: Importing cmdlet 'Set-PSReadLineKeyHandler'. VERBOSE: Importing cmdlet 'Set-PSReadLineOption'. VERBOSE: Importing function 'PSConsoleHostReadLine'.Sydney Smith (@SydneyhSmith) TylerLeonhardt I tested beta4 (On preview 2) on 2 PCs and it looks like it working.
With beta3 if keyboard is on Hebrew and I start the terminal I get the loop, with beta4 I don't have this problem.
Thank youStéphane BARIZIEN (@sba923)
Get-Module PSReadLinemeans that PSRL is not loaded in your session. However, if you runSet-PSReadLineKeyHandleror something in your profile, that will cause module autoloading to load PSRL.We probably load PSRL after profiles are run, but if your profile runs a cmdlet from PSRL, it will cause it to load PSRL and all will be fine.
We can close this issue now as being an external issue fixed in the next release of PSRL but Stéphane BARIZIEN (@sba923) if you have more concerns regarding when PSRL gets loaded, feel free to open a new issue.
Thanks to all who contributed to this fix! ISE's grave is getting deeper ;-)
TylerLeonhardt Yes I will open another issue for the problem where PSRL doesn't get loaded in some circumstances: when this happens not only don't I get PSRL in my VScode session, but also if I load it manually using Import-Module it doesn't behave properly (no syntax highlighting, so history backed by a file on disk....)
Reacted by ExE Boss and TylerLeonhardtOpened #1834
Reacted by TylerLeonhardtStéphane BARIZIEN (@sba923) That link in your comment is broken (leads to: https://github.com/PowerShell/vscode-powershell/issues/url)
Fixed, thanks for the remark.
Reacted by ExE Boss
Issue Description
When I open a folder containing PowerShell scripts, the integrated terminal displays the prompt in an endless loop, as if I would press and hold the Enter key for it to autorepeat.
Attached Logs
See 1539111398-a60423be-01d3-4cc1-83df-f15ead97e8aa1539111394598.zip
Environment Information
Visual Studio Code
PowerShell Information
Visual Studio Code Extensions
Visual Studio Code Extensions(Click to Expand)