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

Question

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

nicenemo opened this issue 3 years ago · 54 comments

nicenemo commented 3 years ago

Windows Terminal version

1.11.2921.0

Windows build number

10.0.22000.348

Other Software

Install Debian Bullseye from the store using my powershell scripts:
https://github.com/nicenemo/wsl-debian-boxes
Install NeoVM 0.6 from source https://github.com/neovim/neovim.
Install lunarvim https://www.lunarvim.org/#opinionated
Use SauceCode PRO NF font
Use GruvBox Material Medium dark color scheme
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.
Install OhMyPosh in Bash and ZSH
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.
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.
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

Edit in neovim with lunarvim: Mardown, JSON, Ruby, Java, logstash config, does not really matter.
Then copy something from Chrome on Windows, e.g. stackoverflow or from notepad or email.
try to paste with 'CTRL+SHIFT+V'
Sometimes the terminal freezes, sometimes not.
Outside neovim try to copy something in the terminal with 'CTRL+SHIFT+C'
Sometimes the terminal freezes, sometimes not.
I have to kill the terminal in the task manager. It is no using High CPU nor is anything else.
Resizing the terminal or switching tabs if I have multiple terminal tabs is not possible either.
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.

Answer 1 · 2021-12-15T21:21:04.000Z

#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

Answer 2 · 2021-12-15T21:53:24.000Z

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 ....

Answer 3 · 2021-12-17T13:42:46.000Z

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

Answer 4 · 2021-12-20T02:07:21.000Z

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 :)

Answer 5 · 2021-12-21T22:05:27.000Z

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.

Answer 6 · 2021-12-25T17:00:02.000Z

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

Answer 7 · 2022-01-03T15:02:18.000Z

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.

Answer 8 · 2022-01-13T18:27:19.000Z

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?

Answer 9 · 2022-03-03T22:35:13.000Z

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?

Answer 10 · 2022-03-03T22:44:24.000Z

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...

Answer 11 · 2022-03-06T04:31:45.000Z

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.

Answer 12 · 2022-03-13T20:56:22.000Z

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.

Answer 13 · 2022-06-08T14:01:09.000Z

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!

Answer 14 · 2022-06-08T14:16:53.000Z

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

Answer 15 · 2022-06-08T14:32:00.000Z

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

Answer 16 · 2022-06-08T14:32:56.000Z

$NativeFunctions=@"
using System;
using System.Runtime.InteropServices;
public class Native {

    [DllImport("user32.dll")]
    public static extern IntPtr GetOpenClipboardWindow();

    [DllImport("user32.dll", CharSet = CharSet.Auto)]
    static extern IntPtr SendMessage(IntPtr hWnd, UInt32 Msg, IntPtr wParam, [Out] System.Text.StringBuilder lParam);

    public static string GetText(IntPtr hWnd)
    {
        // Allocate correct string length first
        // WM_GETTEXTLENGTH = 0x000E
        // WM_GETTEXT = 0x000D
        int length = (int)SendMessage(hWnd, 0x000E, IntPtr.Zero, null);
        System.Text.StringBuilder sb = new System.Text.StringBuilder(length + 1);
        SendMessage(hWnd, 0x000D, (IntPtr)sb.Capacity, sb);
        return sb.ToString();
    }

  }
"@

Add-Type -TypeDefinition $NativeFunctions

$hasClipboard = [Native]::GetOpenClipboardWindow();
if ($hasClipboard -ne 0)
{
    Write-Host [Native]::GetText($hasClipboard);
}
else {
    Write-Host "No one had the clipboard open"
}

Save that as whos-got-my-clipboard.ps1 and run that in a plain old powershell window, and that should print out the window title for the window that's got the clipboard open. That's somewhere to start. It could probably be modified to print out the PID, but let's start here

Answer 17 · 2022-06-08T14:39:07.000Z

Output No one had the clipboard open I will run again with a freeze from a classic powershell terminal ?

Answer 18 · 2022-06-08T14:45:52.000Z

Sorry, to clarify - when the Terminal is in the hung state, in another powershell window, call that

Answer 19 · 2022-06-10T09:02:21.000Z

It froze again this morning. But no app was holding the clipboard.
Note that there are two ways of hanging terminals:

Only one tab hangs. I can still open anew tab and close the old tab.
Everything Windows terminal is frozen I cannot resize or background the terminal or use the mouse. I use Windows X to get a task manager and kill the terminal

Answer 20 · 2022-06-10T14:36:34.000Z

First situation with only 1 tab with Neovim hanging occured: noone was holding the clipboard.

Answer 21 · 2022-06-23T19:18:38.000Z

I'm having the same issue on Ubuntu 22.04 LTS + Neovim 0.8.0.

@zadjii-msft The Output from the provided script was [Native]::GetText 4000696

If I can provide any further information please tell me, I would be glad to help!

Some additional info:

Windows Terminal 1.13.11432.0
Windows build:

Platform ServicePack Version      VersionString
-------- ----------- -------      -------------
 Win32NT             10.0.22000.0 Microsoft Windows NT 10.0.22000.0

neovim 0.8.0-dev built from source on commit c9432528
tmux version 3.2a (the error isn't exclusive to tmux)

I also made the discovery, that if this freeze occurs and you try pasting onto windows notepad it also freezes up. This is also repeatable, so i can open up as many notepad instances as i want, and freeze them until i copy something from windows into my clipboard.

this is what i get when I execute win32 yank with the broken clipboard content:

$ win32yank.exe -o --lf
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: WinAPI Error(0)', src\libcore\result.rs:859
note: Run with `RUST_BACKTRACE=1` for a backtrace.

$  win32yank.exe -o
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: WinAPI Error(0)', src\libcore\result.rs:859
note: Run with `RUST_BACKTRACE=1` for a backtrace.

For those who are just looking for a quick fix: I just completely removed win32yank from /usr/local/bin and C:\tools\neovim\nvim-win64\bin
the registered clipboard provider for neovim is now xclip, i still can paste from windows clipboard into neovim and no further issues observed (so far)

Answer 22 · 2022-06-24T17:20:13.000Z

Upgraded win32yank to version v0.0.4 no issues since. Spent the whole day coding so I guess this resolves the issue (at least on neovims side)

Answer 23 · 2022-06-24T23:34:32.000Z

Wow, I'm really curious as to what they could be doing that'll hang Terminal. Thanks for digging into this!

Answer 24 · 2022-07-03T08:11:44.000Z

@DrGGCoolman how did you go about upgrading it? This pretty much makes the wsl setup unusable when using neovim haha

Answer 25 · 2022-07-04T08:39:20.000Z

@RobertBrunhage I think the easiest way is to just check where on your path win32yank is registered, so on wsl just run which win32yank.exe for me it was /usr/local/bin/win32yank.exe. Then delete it and run :checkhealth inside of neovim to make sure there is no alternative version somewhere else.

once neovim says there is no registered clipboard provider (or lists something like xclip) you can go ahead and drop the latest version of win32yank into /usr/local/bin from here win32yank release v0.0.4
run :checkhealth again and make sure neovim recognizes win32yank and you're done :)

Answer 26 · 2022-07-04T08:47:08.000Z

@DrGGCoolman thanks! Did it yesterday and noticed some other weird issues (sometimes it would print in neovim that it was an error when yanking: related issue). Compiled a PR that wasn't merged and uploaded it in my own branch for now until they resolve and merge it (over a year old though).

Running the following now when setting up win32yank.

curl -sLo/tmp/win32yank.zip https://github.com/robertbrunhage/win32yank/releases/download/v0.0.5/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/

and this in neovim:

if has('wsl')
    let g:clipboard = {
          \   'name': 'wslclipboard',
          \   'copy': {
          \      '+': '/usr/local/bin/win32yank.exe -i --crlf',
          \      '*': '/usr/local/bin/win32yank.exe -i --crlf',
          \    },
          \   'paste': {
          \      '+': '/usr/local/bin/win32yank.exe -o --lf',
          \      '*': '/usr/local/bin/win32yank.exe -o --lf',
          \   },
          \   'cache_enabled': 1,
          \ }
endif

Now it seems to run flawlessly!

Answer 27 · 2022-07-06T11:29:02.000Z

Huh, the win32yank is definitely helpful (related: equalsraf/win32yank#11).

Lunarvim does have an explicit win32yank callout: https://www.lunarvim.org/01-installing.html#tips-for-wsl-2-users

Some WSL2 users have experienced that sourcing the clipboard may be slow. A workaround for that is calling a clipboard manager from the Windows side. Neovim tries using win32yank.exe if it's available. so install it and set the value of clipboard explicitly:

But alas, it seems that OP @nicenemo had already tried removing win32yank entirely, so their issue must lie elsewhere. I'm gonna leave the above comments expanded though, to help anyone else.
At this point, I'm out of ideas for what's causing this hang on the clipboard. If my theory is correct that someone's holding the clipboard, then OP wouldn't be able to paste even in notepad when the terminal is locked up like this.

I don't think there's a good way for us to bail on the copy/paste if we find that the clipboard is locked, either (though I'd love to be proven wrong)

Answer 28 · 2022-08-16T11:07:00.000Z

Been having this issue a lot lately and just tried pasting into notepad after the freeze and sure enough that freezes as well. Thought it was a problem with my vim config at first. Using WSL btw.

Answer 29 · 2022-08-19T11:16:36.000Z

sorry but no reporting

Answer 30 · 2022-08-19T11:22:31.000Z

Interesting, what does that Application Hang event look like?

.... BY ANY CHANCE, are you connected to this Windows machine via Remote Desktop? That would be a wild coincidence this week.

Answer 31 · 2022-08-19T11:44:43.000Z

Not remotem but local. Thinkpad T480.

Keyboard used is a Planck with this firmware https://github.com/nicenemo/franken-planck/tree/main/keymaps/franken-planck It also is hang on the Thinkpad keyboard

Answer 32 · 2022-08-19T11:47:21.000Z

I noticed that it may be duration of use or time related. The problems start to occur after noon CEST. After a morning in NeoVim. A complete shutdown of the laptop and a restart plus lunch break seems to fix it. After 1 hour at 14:07 CEST I get my first hang again.

Answer 33 · 2022-08-19T16:11:51.000Z

I find that sometimes clicking on another window outside of the terminal and then going back helps unfreeze it. This problem is a massive pain.

Answer 34 · 2022-08-23T15:57:43.000Z

I was able to grab the XML error reporting before killing Windows terminal.
Not sure if it helps. Note that I am actually Running Windows 11 and it is still reporting 10?
This hang occured when I tried to copy something from the Chrome web browser on Windows into a Neovim in WSL2.

<?xml version="1.0" encoding="UTF-16"?>
<WERReportMetadata>
	<OSVersionInformation>
		<WindowsNTVersion>10.0</WindowsNTVersion>
		<Build>22000</Build>
		<Product>(0x30): Windows 10 Pro</Product>
		<Edition>Professional</Edition>
		<BuildString>22000.856.amd64fre.co_release.210604-1628</BuildString>
		<Revision>856</Revision>
		<Flavor>Multiprocessor Free</Flavor>
		<Architecture>X64</Architecture>
		<LCID>1033</LCID>
		<BuildLayers>
		</BuildLayers>
	</OSVersionInformation>
	<ProblemSignatures>
		<EventType>MoAppHangXProc</EventType>
		<Parameter0>Microsoft.WindowsTerminal_1.14.1963.0_x64__8wekyb3d8bbwe</Parameter0>
		<Parameter1>praid:App</Parameter1>
		<Parameter2>1.14.2207.15003</Parameter2>
		<Parameter3>62d1f0b7</Parameter3>
		<Parameter4>004c</Parameter4>
		<Parameter5>67246144</Parameter5>
		<Parameter6>NO_PACKAGE</Parameter6>
		<Parameter7>mstsc.exe</Parameter7>
		<Parameter8>10.0.22000.675</Parameter8>
	</ProblemSignatures>
	<DynamicSignatures>
		<Parameter1>10.0.22000.2.0.0.256.48</Parameter1>
		<Parameter2>3072</Parameter2>
		<Parameter22>004c3c0385a6cee4aab23f55a8b7676f</Parameter22>
		<Parameter23>d783</Parameter23>
		<Parameter24>d78330958d5fe08ded8eba3438f0e743</Parameter24>
		<Parameter25>004c</Parameter25>
		<Parameter26>004c3c0385a6cee4aab23f55a8b7676f</Parameter26>
		<Parameter27>d783</Parameter27>
		<Parameter28>d78330958d5fe08ded8eba3438f0e743</Parameter28>
	</DynamicSignatures>
	<SystemInformation>
		<MID>7CF03625-D6C9-481F-802F-68FFC3095777</MID>
		<SystemManufacturer>LENOVO</SystemManufacturer>
		<SystemProductName>20L5CTO1WW</SystemProductName>
		<BIOSVersion>N24ET69W (1.44 )</BIOSVersion>
		<OSInstallDate>1633459894</OSInstallDate>
		<OSInstallTime>1601-01-02T22:06:51Z</OSInstallTime>
		<TimeZoneBias>-01:00</TimeZoneBias>
	</SystemInformation>
	<SecureBootState>
		<UEFISecureBootEnabled>1</UEFISecureBootEnabled>
		<PolicyPublisher>{77fa9abd-0359-4d32-bd60-28f4e78f784b}</PolicyPublisher>
	</SecureBootState>
	<ReportInformation>
		<Guid>1bc145c6-3b01-4589-923d-af9b6b564e8d</Guid>
		<CreationTime>2022-08-23T15:49:21Z</CreationTime>
	</ReportInformation>
</WERReportMetadata>

Update:
After copy pasting the above XML here the terminal was unstuck and I succeeded in a second attempt of pasting the data from Chrome into NeoVim.
This was near 18:00 CEST.

Answer 35 · 2022-08-23T16:23:53.000Z

Not remotem but local. Thinkpad T480. Keyboard used is a Planck with this firmware https://github.com/nicenemo/franken-planck/tree/main/keymaps/franken-planck It also is hang on the Thinkpad keyboard

I've just noticed that you are using a ThinkPad. I have a ThinkPad T460s and a T480s. Could it be possible that the people experiencing this problem are all ThinkPad users?

If it wasn't for the fact that tmux sessions persist after kill the hung terminal, I certainly would have dumped Windows Terminal by now.

Answer 36 · 2022-09-01T15:14:24.000Z

This T480 will no longer be available to me in 3 weeks because of a new job. I have no private machines available with Windows yet.
I hope to have some spare time to test in the future:

I have a Thinkpad 450s that officially does not run Windows 11. So I should install 10 on it again.
I have some parts that can become another Windows 10 PC.
I have a Elitedesk G4 arriving soon from an auction that can run 11.
I can try run 11 from a vm on Proxmox on a Prodesk mini, however I think that is not a valid test, as it would be RDP too. It would also mean nested virtualization.
Other than that, I think this really is up to Microsoft to fix. With the private machines I will be able to share more data if available.

Answer 37 · 2022-09-04T06:32:41.000Z

So what are you using as a clipboard manager now? xclip? Can you try using xsel instead and see if it makes a difference? In order to check if it was xclip I installed it back and suffered multiple freezes within 10 mins of constantly copy-pasting across wsl and windows.

I can say few things about the issue:

Its not specific to neovim or windows terminal, as using echo "hello" | xclip -selection clipboard also freezes on its own. And pasting on MS Edge also freezes.
It only hangs when the we paste the item and not while copying.
Issue is not specific to Thinkpads.

Answer 38 · 2022-09-04T09:04:57.000Z

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.

Answer 39 · 2022-09-04T09:16:27.000Z

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?

Answer 40 · 2022-09-04T10:02:38.000Z

@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.

Answer 41 · 2022-09-04T16:36:27.000Z

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.

Answer 42 · 2022-09-09T00:19:37.000Z

@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!

Answer 43 · 2022-09-09T05:50:36.000Z

#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.

Answer 44 · 2022-09-09T06:07:46.000Z

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.

Answer 45 · 2022-09-09T18:37:00.000Z

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.

Answer 46 · 2023-01-09T17:16:07.000Z

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.

Answer 47 · 2023-01-09T19:12:51.000Z

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

Answer 48 · 2023-01-11T17:31:42.000Z

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

Answer 49 · 2023-01-26T11:04:19.000Z

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.

Answer 50 · 2023-02-23T01:31:08.000Z

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

Answer 51 · 2023-04-12T21:43:52.000Z

@nicenemo Did the above solve the issue for you?

Answer 52 · 2023-04-21T20:58:05.000Z

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.

Answer 53 · 2023-04-21T20:58:22.000Z

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.

Answer 54 · 2023-04-21T20:58:28.000Z

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.