Shell: Pop Shell makes Gnome unresponsive after login [Appears to be Wayland only]

Created on 15 Apr 2020 · 27Comments · Source: pop-os/shell

As the title says, after login no command affects gnome and the only way to restart is to hard reset the machine into a text only interface and deleting the extension from there.

Also I noted that my clock did not change whilst gnome was unresponsive

Manjaro Gnome 3.36
Wayland

wayland

Source

ccwky11

👍62

Most helpful comment

If it's support issue (no support for Wayland), extension should auto-disable on Wayland but not crash the OS. So I think first thing to do is prevent hangs, then that fix will get removed when somebody implements Wayland support,

sh7dm on 17 May 2020

👍17

All 27 comments

Yep, same happens to me, when enabled it just freezes and only the hard reset worked. I could disable it only reverting to an X session.

kowalski7cc on 17 Apr 2020

Can confirm this bug

MaCroX95 on 18 Apr 2020

Same.

luispabon on 18 Apr 2020

Yes. The extension doesn't seem to work under Wayland as of yet. I look forward to using it on Fedora 32 when it does.

mneumann-dev on 18 Apr 2020

👍11 ❤3

Same on Arch

yasoomn on 22 Apr 2020

👍5

NEW UPDATE

It appears that as of the latest commit, it works, until the extension attempts to autotile anything, this may have been the case all along, I am uncertain, though I can confirm that this being enabled does not cause gnome to be unresponsive, only when autotiling does gnome become unresponsive and require a hard reset

ccwky11 on 25 Apr 2020

👍5

Can confirm it - when auto-tile is on and you log in to Wayland session the UI freezes with no mean to reset it except hard-reset.
Manjaro 20.

rushills on 1 May 2020

I can confirm this as well - I have the same behavior as rushills on Manjaro 20. I also should note that even when running on X, the interface locks up (mouse can move, but nothing else is responsive) when using pop-shell. This locking up occurs seemingly randomly.

evansgroup on 1 May 2020

I'm also getting this issue. Extension loads fine with "tile shells" disabled - but if it's enabled, as soon as you attempt to open anything i.e. gnome-terminal, GNOME becomes completely unresponsive and requires a hard reboot. Haven't yet found a program to run that _doesn't_ support fractional scaling to see whether this is caused by #211 (update: tried running 'xeyes' via XWayland which I would assume has no concept of fractional scaling, still encountered the issue).

Have captured the journald output from gnome-shell with journalctl -xe -f /usr/bin/gnome-shell | tee pop.log. The output I see consistently just before crashing is like this:

May 01 17:01:09 annwn gnome-shell[115385]: pop-shell:  [INFO] tile by default enabled
May 01 17:01:09 annwn gnome-shell[115385]: pop-shell: [DEBUG] blocking signals for 0,0
May 01 17:01:09 annwn gnome-shell[115385]: pop-shell:  [INFO]

                                            Fork(0,0) [1928,8,2544,1400]: {
                                               workspace: (0),
                                               left:  Window(0,0) (Rect(2680,270,1138,805)),
                                             }
-- Reboot --

May 01 17:06:01 annwn gnome-shell[1948]: pop-shell:  [INFO] tile by default enabled
May 01 17:06:01 annwn gnome-shell[1948]: pop-shell: [DEBUG] blocking signals for 0,0
May 01 17:06:01 annwn gnome-shell[1948]: pop-shell:  [INFO]

                                          Fork(0,0) [1928,8,2544,1400]: {
                                             workspace: (0),
                                             left:  Window(0,0) (Rect(1920,0,2560,1416)),
                                           }
May 01 17:06:01 annwn gnome-shell[1948]: pop-shell: [DEBUG] Window(0,0) maximization changed
May 01 17:06:01 annwn gnome-shell[1948]: pop-shell: [DEBUG] blocking signals for 0,0
May 01 17:06:01 annwn gnome-shell[1948]: pop-shell: [DEBUG] Window(0,0) maximization changed
May 01 17:06:01 annwn gnome-shell[1948]: pop-shell: [DEBUG] blocking signals for 0,0
May 01 17:06:01 annwn gnome-shell[1948]: pop-shell: [DEBUG] unblocking signals for 0,0
May 01 17:06:01 annwn gnome-shell[1948]: pop-shell: [DEBUG] unblocking signals for 0,0
May 01 17:06:02 annwn gnome-shell[1948]: Error in size change accounting.
-- Reboot --

May 01 17:12:51 annwn gnome-shell[1941]: pop-shell:  [INFO] tile by default enabled
May 01 17:12:51 annwn gnome-shell[1941]: pop-shell: [DEBUG] blocking signals for 0,0
May 01 17:12:51 annwn gnome-shell[1941]: pop-shell:  [INFO]

                                          Fork(0,0) [1928,8,2544,1400]: {
                                             workspace: (0),
                                             left:  Window(0,0) (Rect(1920,0,2560,1416)),
                                           }
May 01 17:12:51 annwn gnome-shell[1941]: pop-shell: [DEBUG] blocking signals for 1,0
May 01 17:12:51 annwn gnome-shell[1941]: pop-shell:  [INFO]

                                          Fork(0,0) [1928,8,2544,1400]: {
                                             workspace: (0),
                                             left:  Window(0,0) (Rect(1920,0,2560,1416)),
                                           }
                                          Fork(1,0) [4488,368,1904,1040]: {
                                             workspace: (0),
                                             left:  Window(1,0) (Rect(4480,360,1920,1056)),
                                           }
May 01 17:12:51 annwn gnome-shell[1941]: pop-shell: [DEBUG] Window(0,0) maximization changed
May 01 17:12:51 annwn gnome-shell[1941]: pop-shell: [DEBUG] blocking signals for 0,0
May 01 17:12:51 annwn gnome-shell[1941]: pop-shell: [DEBUG] Window(0,0) maximization changed
May 01 17:12:51 annwn gnome-shell[1941]: pop-shell: [DEBUG] blocking signals for 0,0
May 01 17:12:51 annwn gnome-shell[1941]: pop-shell: [DEBUG] Window(1,0) maximization changed
May 01 17:12:51 annwn gnome-shell[1941]: pop-shell: [DEBUG] blocking signals for 1,0
May 01 17:12:51 annwn gnome-shell[1941]: pop-shell: [DEBUG] Window(1,0) maximization changed
May 01 17:12:51 annwn gnome-shell[1941]: pop-shell: [DEBUG] blocking signals for 1,0
May 01 17:12:51 annwn gnome-shell[1941]: pop-shell: [DEBUG] unblocking signals for 0,0
May 01 17:12:51 annwn gnome-shell[1941]: pop-shell: [DEBUG] unblocking signals for 0,0
May 01 17:12:51 annwn gnome-shell[1941]: pop-shell: [DEBUG] unblocking signals for 1,0
May 01 17:12:51 annwn gnome-shell[1941]: pop-shell: [DEBUG] unblocking signals for 1,0
May 01 17:12:51 annwn gnome-shell[1941]: Error in size change accounting.
May 01 17:12:52 annwn gnome-shell[1941]: Error in size change accounting.
-- Reboot --

Running Fedora 32 (so GNOME 3.36.2) on Wayland, nouveau driver. Also have the "dash to panel" extension installed.

erinaceous on 1 May 2020

Also affects Pop!_OS 20.04.

daveriedstra on 2 May 2020

👍9

Same in Pop!_OS 20.04 (upgraded from 19.10)

alberpilot on 6 May 2020

Adding a +1 to this thread, pop shell is locking up my system whenever I enable "Tile Windows" in the extension.

OS: Arch
Gnome Version: 3.36.2
Windowing: Wayland

Let me know if I can dig in some more to help repro.

dencold on 8 May 2020

👀2

Running Pop!_OS 20.04 I get the same. Attempting to enable auto-tiling in a wayland session locks up the entire desktop and requires a hard reset.

whereswaldon on 9 May 2020

Same here. See duplicate https://github.com/pop-os/pop/issues/1013 for more details.

r0ckarong on 12 May 2020

Can confirm this (Manjaro Gnome 3.36). When a window is opened in Wayland session with auto-tiling enabled, VM freezes

sh7dm on 16 May 2020

For those who have this issue as well, but no more information to add, please just give the issue a :+1: and avoid repeating what has been said before.

Those who watch this issue want to be notified about progress and the noise caused by all the "same here" comments makes it rather annoying.

Thanks!

Finnerale on 16 May 2020

👍11

From the looks of it, this issue could be renamed to "Wayland Support", since it appears to not have yet been considered. @mmstick could you give us some input?

RicardoEPRodrigues on 17 May 2020

👍5

sh7dm on 17 May 2020

👍17

Experiencing a similar crash here. Can't give logs, but when activating tile windows and openning any application, there is a major crash only solved by hard reset (as the issue title). When using Gnome over Xorg the extension works fine with tile windows feature.

williamguilhermesouza on 3 Jun 2020

Same here. Using this extension on Wayland results in a full system freeze and the only way to recover is by pressing and holding the power button to reboot then changing back to X11 from the login screen.

Perdyx on 13 Jun 2020

It does this on my laptop (Surface Book 2) and my desktop AMD CPU and GPU. Any progress towards a fix?

kachapman on 18 Jun 2020

👍1

I didn’t have this issue from the start which I found extremely strange, so it took me a while to figure out what setting I changed that caused this on my setup:
I have only this issue when ‘show Active hint‘ is disabled at startup.
When deactivating ‘show Active hint‘ there is no issue until restart.
Maybe you can try to see if this works for you? Maybe this can help with reproducing the bug for the devs?
I am also using wayland.

kertase on 3 Jul 2020

I didn’t have this issue from the start which I found extremely strange, so it took me a while to figure out what setting I changed that caused this on my setup:
I have only this issue when ‘show Active hint‘ is disabled at startup.
When deactivating ‘show Active hint‘ there is no issue until restart.
Maybe you can try to see if this works for you? Maybe this can help with reproducing the bug for the devs?
I am also using wayland.

So you are saying that the issue only exists if you are not using the hint feature? If I even try to enable tiling while in a Wayland environment, it insta-locks the system.

kachapman on 3 Jul 2020

The behaviour @kertase reported is on newer version. New versions don't enable tiling on Wayland to avoid that lockup.

sh7dm on 3 Jul 2020

I didn’t have this issue from the start which I found extremely strange, so it took me a while to figure out what setting I changed that caused this on my setup:
I have only this issue when ‘show Active hint‘ is disabled at startup.
When deactivating ‘show Active hint‘ there is no issue until restart.
Maybe you can try to see if this works for you? Maybe this can help with reproducing the bug for the devs?
I am also using wayland.

So you are saying that the issue only exists if you are not using the hint feature? If I even try to enable tiling while in a Wayland environment, it insta-locks the system.

Yes, exactly when I don’t disable the hint feature at startup (or I Enable/Disable it before opening a window) I don’t get a lock up and my windows get tiled. If I have it disabled from the start, my system locks up, and I need to hard reset.

Now I am using a New Version but it is the same on the default package in the repo of my distro(Manjaro/arch).

kertase on 3 Jul 2020

The behaviour @kertase reported is on newer version. New versions don't enable tiling on Wayland to avoid that lockup.

Indeed, since an update just after I wrote the last comment there is no tilling at all any more. Before that tiling would work the way I described earlier…

Hope it will soon work on Wayland because I really enjoy the tiling.

kertase on 7 Jul 2020

👍12

Any update on this issue?