microsoft / wslg

Enabling the Windows Subsystem for Linux to include support for Wayland and X server related scenarios
MIT License
10.24k stars 306 forks source link

Applications randomly become unresponsive and require a WSL restart to recover #405

Open davwheat opened 3 years ago

davwheat commented 3 years ago

Environment

Windows build number: 22000.120
Your Distribution version: Ubuntu 20.04
Your WSLg version: 1.0.24

Steps to reproduce

This is the tricky part. It seems to happen randomly. I've only noticed it while using GitKraken, as that's almost the only app I use in WSLg.

WSL logs:

You can access the wslg logs using explorer at: \\wsl$\<Distro-Name>\mnt\wslg (e.g.: \\wsl$\Ubuntu-20.04\mnt\wslg)

Expected behavior

Programs work as normal.

Actual behavior

Some applications (in my experience, it has often been while using GitKraken) unexpectedly hang on the Windows desktop. It is impossible to interact with the apps or the window itself (cannot be moved, etc.), or open any new apps afterwards.

Killing the apps with htop leaves the window open in Windows. A simple wsl --shutdown, however, does fix the issue.

NOTE: By default, .X11-unix is not being linked to /mnt/wslg/.X11-unix. I do not override /tmp manually. Creating the link manually fixes the issue.

aedryan commented 3 years ago

I'm curious if you're using Docker (and optionally devcontainers also) in conjunction with Gitkraken? Just asking as it may be a contributing factor. I am experiencing this same issue and working around it in the same fashion.

davwheat commented 3 years ago

Yes I am! I'm using Docker containers with volumes created from local folders in WSL. I'm not using dev containers.

The issue only occurs when interacting inside these folders (which is basically the only thing I use WSL for, so if it did happen outside this, I likely wouldn't even notice).

More recently, importantly after a full reinstall of my WSL distro, the issue with .X11-unix is fixed, but I still get issues with WSL. In fact it's resulting in WSL crashing as a whole. Attempting to access WSL after this results in error 0xffffffff (or whatever it is with all F's) and requires a full WSL restart.

It only happens on one of my PCs, which is a Ryzen 4000 series laptop (TongFang PN5NU1G):

This only happens if I'm using WSLg in some form. If I only use VS Code's built-in git client, it works fine.

epiciskandar commented 2 years ago

Same here with Intellij / Android Studio, nothing noticeable in logs, just every window stuck there, you even cannot close them.

RiccardoManzan commented 2 years ago

I have this same exact issue. It is drammatic when you have to

Neither i found any interesting log. I just noticed that when everything is ok i am able to kill weston process from wslg user. When apps freeze, then i am no able to kill it.

RiccardoManzan commented 2 years ago

This issue keeps happening randomly for me. I think that #472 , #539 , #605 #643 and #645 could be related to this as nothing looks broken in logs but actually applications are freezed and cannot be moved or closed and the only solution is restarting the whole wsl. Across those issues i collected some hypotesis:

Unfortunately not in all issues has been shared the stderr.log file, which could contain some crucial information. Unfortunately again this usually happens when i have not time for debugging.

RiccardoManzan commented 1 year ago

After 1.0 update i stopped experiencing this unfortunate issue. Since then, i got no freeze and just a couple of crashes probably due to application crashes and not upon window management.

There are still some minor issues when launching some applications that can be fixed simply by double clicking title bar de-maximizing and then re-maximizing the issued application.

douglasg14b commented 1 week ago

I experience this weekly still, unfortunately sometimes wsl --shutdown does not resolve the issue because the shutdown command hangs as well.