Windows terminal randomly freezes with Neovim 0.6 in debian Bullseye when using MCTRL>-<SHIFT>C or <CTRL-SHIFT>V

[nicenemo]

Windows Terminal version

1.11.2921.0

Windows build number

10.0.22000.348

Other Software

1. Install Debian Bullseye from the store using my powershell scripts:
   https://github.com/nicenemo/wsl-debian-boxes
2. Install NeoVM 0.6 from source https://github.com/neovim/neovim.
3. Install lunarvim https://www.lunarvim.org/#opinionated
4. Use SauceCode PRO NF font
5. Use GruvBox Material Medium dark color scheme
6. Software installed with Ansible using my playbook
   https://github.com/nicenemo/win-dev-playbook
   Only The Debian stuff. Calling chocolatey is not working perfect yet and therefore commented out.
7. Install OhMyPosh in Bash and ZSH
8. I have systemd enabled with Distrod after installing my own updated Debian. https://github.com/nullpo-head/wsl-distrod
   Then I have a bash shell. However the same also happens without having distrod enabling systemd.
9. Memory in WSL is 24Gb and swap of 24Gb.
   10 System Thinkpad T480 with 32Gb of memory.
   (But also have this on a HP Prodesk 400 G4.) And can test it on a T450s with Windows 10.
10. all updates installed.

fragments of my config

[...]
"font": 
                {
                    "face": "SauceCodePro NF"
                },
[...]

Use color scheme:

[...]
 "colorScheme": "GruvboxMaterialMediumDark",
[...]
 {
            "background": "#282828",
            "black": "#665C54",
            "blue": "#7DAEA3",
            "brightBlack": "#928374",
            "brightBlue": "#7DAEA3",
            "brightCyan": "#89B482",
            "brightGreen": "#A9B665",
            "brightPurple": "#D3869B",
            "brightRed": "#EA6962",
            "brightWhite": "#D4BE98",
            "brightYellow": "#D8A657",
            "cursorColor": "#FFFFFF",
            "cyan": "#89B482",
            "foreground": "#D4BE98",
            "green": "#A9B665",
            "name": "GruvboxMaterialMediumDark",
            "purple": "#D3869B",
            "red": "#EA6962",
            "selectionBackground": "#FFFFFF",
            "white": "#D4BE98",
            "yellow": "#D8A657"
        },

Linux config:

[...]
 {
                "closeOnExit": "always",
                "colorScheme": "GruvboxMaterialMediumDark",
                "font": 
                {
                    "face": "SauceCodePro NF"
                },
                "guid": "{c31b85d2-61c0-5be6-9284-2ac955dcc417}",
                "hidden": false,
                "name": "nemolinux",
                "source": "Windows.Terminal.Wsl",
                "startingDirectory": "\\\\wsl.localhost\\nemolinux\\home\\kruse"
            },
[...]

Steps to reproduce

1. Edit in neovim with lunarvim: Mardown, JSON, Ruby, Java, logstash config, does not really matter.
2. Then copy something from Chrome on Windows, e.g. stackoverflow or from notepad or email.
3. try to paste with 'CTRL+SHIFT+V'
4. Sometimes the terminal freezes, sometimes not.
5. Outside neovim try to copy something in the terminal with 'CTRL+SHIFT+C'
6. Sometimes the terminal freezes, sometimes not.
7. I have to kill the terminal in the task manager. It is no using High CPU nor is anything else.
8. Resizing the terminal or switching tabs if I have multiple terminal tabs is not possible either.
9. Also maximize or minimize does not work.

Happens in Windows 10 as well as Windows 11. With Release and preview version.

Expected Behavior

Copy and Paste just works in a Debian terminal.

Actual Behavior

Terminal freezes sometimes when trying to copy or paste with Control Shift-C or Control-Shift V.
I experience it more often in NeoVIM with LunarVIM. Also had this in Windows 10 in the past.

[zadjii-msft]

#10157 looks related, but that never got driven to a resolution. Any chance you're using any accessibility software of any sort? (Narrator, Magnifier, NVDA, JAWS, etc?)

Since the Terminal isn't pegging a CPU, it's not an infinite loop, nor is it a stack overflow of some sort (that would eventually crash the Terminal). I'm suspecting the UI thread is waiting on the buffer lock, which some other thread forgot to unlock.

ninja edit: leaving this open so that we can actually confirm that this is the accessibility fix from before the holidays, the one with the locking

[nicenemo]

I am not using accessibility software nor is Autohotkey or something similar installed.
It is not something trivial like Control S/Control Q. It is not neovim alone, also just in the console.
There was another issue regarding character encoding that looked related but already closed.
I am using a nerdfont.

Is there a log or dump file I can look at or force create?
Anything you need to recreate it?

Annoying is that I just editted a lot and then just did not save ;). copy/paste and ....

[nicenemo]

Update: I now also have it when 'yanking' a line in Neovim using yy.

[eastwood]

I experience similar issues. I usually get about a dozen copy/paste actions per session. Then any subsequent attempts proceed to completely lock the UI of windows terminal.

I can hear a bell notification when trying to interact, but I'm forced to end task + reopen. Luckily i'm using tmux, so it's not too bad. I'm happy to provide any additional information if it'll help :)

[davclark]

I figure I should chime in here also. I think I'm only getting the occasional hang in neovim, and maybe only with "+p and the like (which is also calling out to win32yank.exe from the windows runtime distro of neovim... so it may not be the terminal. I can remove this program from the WSL2 path if you'd like, though.

I'm also using sticky keys.

I had chimed in on #10157 but this feels like a more suitable place to discuss this problem, and it's finding a few folks with similar issues.

Note also that I tried using the preview version of terminal, and that didn't resolve the problem.

Worth noting that I'm on Ubuntu-20.04, not bullseye.

[goldcoders]

im also facing issue, but different keys being stroke that freeze my current session in vim
at first i thought i was my profile and zshrc config, after digging in it is in my nvim config
if i remove everything in neovim config my session wont freeze when pressing
x, dd, pp , yy
most of the time its x ,
i have been testing it out to workout with vscode
g:vscode i think always freeze it if it is not in my config
i wont face any issue...

I have 2 neovim installed one on windows that is working fine, and one on wsl2 ubuntu
i hope this gets fix since only my windows workflow is fuck up

my macos and artix linux works just fine even if there is g:vscode check in my config..

i can confirm this only happens in windows terminal since im also using alacritty
since my option now is use alacritty when using wsl since windows terminal has fuck up nvim

and for some reason it always happen when my laptop is plugged in
i did try same config one is not plug in and unplugged.
same config that fuck up on plugged has not problem when not plug in which is an odd scenario

[zadjii-msft]

I think I'm only getting the occasional hang in neovim, and maybe only with "+p and the like (which is also calling out to win32yank.exe from the windows runtime distro of neovim... so it may not be the terminal. I can remove this program from the WSL2 path if you'd like, though.

You know, that sounds exactly like the sort of thing that would cause this. Otherwise I don't have any idea how contents from the vim inside WSL would be able to set the Windows clipboard with yy. I'd definitely try removing that, if only to narrow the problem space down.

[davclark]

I'm experiencing the same hang in the VS Code terminal, so I don't think this is a Terminal issue per se? Or does VS Code share code with this project?

[davclark]

Still quite curious in finding a solution for this. I'm on bare-metal Ubuntu for now, and genuinely missing the WSL2 experience apart from this critical issue for me.

Is there anything I can do to help test?

[zadjii-msft]

I'm assuming that removing win32yank.exe didn't help then? That was my main theory.

The Terminal and the VsCode terminal share code in the sense that they both share the ConPTY underpinnings, but the version VsCode uses would likely be months/years behind the version shipped with the Terminal, and would also rule out "the accessibility fix from before the holidays", whichever that might have been...

[davclark]

Exactly. Sorry, I should've been more clear about that, but i did remove the win32yank link from the Ubuntu side and continued to experience sporadic freezes.

[nicenemo]

Did remove win32yank too. I completely removed the windows version of Neovim.

I had both the Windows as well as the Linux version of Neovim. Actually only using the Linux version.

Removing of win32yank did not help.

[nicenemo]

I have several freezes per hour in neovim or the commandline now using the release version.
Please advise on how to help to sort this out. I am really considering moving away from ms-terminal and maybe WSL2.

This issue is a productivity blocker!

[zadjii-msft]

Honestly, I'm not even sure where to begin investigating next. Maybe share your whole settings.json file?

If it repros outside of neovim, then great, we can remove that from the problem space. Does it happen regardless of shell in WSL? Like, if your default shell is bash, does this repro in zsh or fish? Maybe this has something to do with inputrc.

Maybe there's something else that's got the clipboard locked for some reason, so the Terminal hangs attempting to open the clipboard. TerminalPage::_CopyToClipboardHandler is called on the UI thread, so if it can't set the content, then that would block the UI thread. We can't call this on the BG though.

I might be able to whip up a powershell script that calls user32!GetOpenClipboardWindow to try and figure out who's got the clipboard locked

[nicenemo]

I am using Debian with bash. I also use zsh. Same problem.
Neovim + Lunarvim seems to be an accelerator for the problem but it happens on only the console too.
I included my settings.json. I shared my scripted Debian setup at the start of this issue via my github repos.

settings.zip

[nicenemo]

I tried xclip, and of course that just worked for now but might random freeze in the future.
I removed xclip and have only xsel installed for now. I will try for a week and see if that helps.

Not sure if it is related. After trying xclip with pasting into notepad, dmesg showed this:

Note again, it did not hang yet.

[nicenemo]

The xsel equivalent of the xclip command is:

echo "I am sorry but it does not freeze from xsel" | xsel -i -b

For testing would it help to run this with while true with another while true loop pasting from PowerShell not running in not a Windows Terminal using a timestamps and sequence numbers?

[tusharsnx]

@nicenemo I'll say go ahead and run the command, it might reveal some pattern for these random freezing. As of now its difficult to reproduce it on our own.
you might wanna try it with xclip as well b/c we dont know the source of the problem yet.

[tusharsnx]

I may have found the root cause. The issue seems to be that xclip prematurely exits without waiting for paste events. This can be seen every time wsl is booted from shutdown, but it also happens when xclip is not working in the background for a long time.

$ echo "hello" | xclip -verbose -selection c
Connected to X server.
Using selection: XA_CLIPBOARD
Using UTF8_STRING.
Waiting for selection requests, Control-C to quit
  Waiting for selection request number 1

It exits right after printing this output. If I now try to paste on any windows application, it would freeze.

Now terminate wsl with wsl --shutdown then open a new tab in the terminal and run the same command twice without trying to paste in-between. You can see the xclip is waiting for the paste event and pasting would not freeze like before.

[eggbean]

@tusharsnn I have uninstalled xclip and installed xsel and since then for the last few days I have not experienced this annoying problem. I didn't want to reply before I was sure. Thanks a lot!

[nicenemo]

#10157 looks related, but that never got driven to a resolution. Any chance you're using any accessibility software of any sort? (Narrator, Magnifier, NVDA, JAWS, etc?)

Since the Terminal isn't pegging a CPU, it's not an infinite loop, nor is it a stack overflow of some sort (that would eventually crash the Terminal). I'm suspecting the UI thread is waiting on the buffer lock, which some other thread forgot to unlock.

ninja edit: leaving this open so that we can actually confirm that this is the accessibility fix from before the holidays, the one with the locking

Not using accessibility features. Thank you for asking.

[tusharsnx]

This issue is windows terminal blocks forever for the paste content, and the reason is wsl unable to provide it.
My observation is that some windows apps(e.g. MS Edge) are resilient to such freezes and comes back alive after few seconds after freezing, But windows terminal may/may not unfreeze and has to be forced close.

[DHowett]

That's a nice, concise summary. We should guard reading the clipboard with a timeout so that we don't just hang if the application on the other end (producing the clipboard content) is acting up.

[ryanjdillon]

I just updated my WSL and started experiencing this error on yank. I was also using Neovim, but v0.4.4 app image. Using xsel made neovim freeze on open, but updating my neovim app image to v0.8.2 made everything run fine.

[zadjii-msft]

Huh, this is an interesting thread: neovim/neovim#19204

[ryanjdillon]

Started happening again today. Following the link you sent, I then found this and then added the following to my nvim config (along with the comment to use has("wsl") for neovim:

if has("wsl")
  augroup Yank
    autocmd!
    autocmd TextYankPost * :call system('clip.exe ',@")
  augroup END
endif

Which still yields freezing

[db-qc]

Hi, just to add my viewpoint.

I've noticed it's very easy to crash neovim running inside WSL if I vi' then try and paste something from clipboard with CTRL+SHIFT+V.

[james1236]

All inside WSL, doing sudo apt-get remove xclip and then following the commands to install win32yank taken from here fixed it!

curl -sLo/tmp/win32yank.zip https://github.com/equalsraf/win32yank/releases/download/v0.0.4/win32yank-x64.zip
unzip -p /tmp/win32yank.zip win32yank.exe > /tmp/win32yank.exe
chmod +x /tmp/win32yank.exe
sudo mv /tmp/win32yank.exe /usr/local/bin/

Specifically for those using neovim, using the clipboard took about 500ms after this, so I had to set vim.opt.clipboard = "" in my lua config

[lhecker]

@nicenemo Did the above solve the issue for you?

[microsoft-github-policy-service]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

[microsoft-github-policy-service]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

[microsoft-github-policy-service]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.