gnome-shell freezes when opening applications/windows that remember their previous size+position
Affected version
- Arch Linux
- gnome-shell 1:45.1-1 as packaged by archlinux
- only observed on wayland
- I do not use any gnome extensions
Bug summary
When opening certain applications (or secondary windows of said applications) gnome-shell freezes. Switching to tty3 reveals that gnome-shell uses 100% CPU. Only way to resume operations (that I am aware) is to hard reset gnome via $ systemclt restart gdm.service
.
Steps to reproduce
This reproduction works reliably on my system:
- My monitor setup:
- Primary monitor: 3840x2160, screen scale 200%
- Secondary monitor: 1920x1080, screen scale 100%, positioned to the right of primary monitor
- Log into Gnome 45.1 (Wayland) from GDM.
- Launch gedit (version 46.1)
- Move gedit to the secondary monitor
- press Super + Left to snap gedit to the left half of the secondary monitor (or the right, does not matter)
- close gedit by clicking on the X in the top right
- open gedit
Now gnome-shell is frozen.
- switch to tty3
$ systemctl restart gdm.service
- log into Gnome 45.1 (Wayland) from GDM
- open gedit
gnome-shell is frozen AGAIN!
- on tty3,
$ systemctl restart gdm.service
- log into Gnome 45.1 (Wayland) from GDM
- make the screen scales of both monitors identical, i.e. set the screen scale of secondary monitor (1920x1080) to 200% or of the primary monitor to 100%
- open gedit
Now gedit opens on the primary monitor instead of the previously saved position (snapped to left side of secondary monitor).
Side notes
- The freeze only occurs when trying to open applications that remember their previous size+position. I can reproduce this with:
gedit
,qalculate-gtk
, but not withgnome-terminal
- The freeze only happens with native Wayland applications.
- The freeze only happens when the screen scales are different.
- The freeze does not happen if the application's previous state was "snapped to half of on the primary monitor"
I can reproduce this even with Firefox and the session-wide environment variable MOZ_ENABLE_WAYLAND=1
:
When I already have a firefox window that is snapped to half of my secondary screen and then open a new firefox window.
What happened
gnome-shell freezes and stops reacting or drawing anything new on the screen.
I can switch to tty3 and access the system. According to htop, gnome-shell uses up 100% CPU while it is frozen.
I need to $ systemctl restart gdm.service
to get back to working, however all unsaved work is lost.
Even a restart of gdm, or a reboot of the system will not completely solve the problem. As described above in steps 7.–10., as long as the application tries to open a window in a previously saved location, gnome-shell freezes.
What did you expect to happen
I expect gedit to appear in the same position where I closed it.
Relevant logs
Since gnome-shell does not crash, I don't have a core dump to analyze. Is there a way that I can provide better information?
The only thing I see is in journalctl
, where I have hundreds of thousands of messages. The first entries look like this:
Nov 11 00:21:06 umoja gnome-shell[1429]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals conn>
The offending signal was window-added on MetaWorkspace 0x56280e5ddc70.
== Stack trace for context 0x56280cf89cd0 ==
#0 56280d051408 i resource:///org/gnome/shell/ui/init.js:21 (27e3fab70ba0 @ 48)
Nov 11 00:21:06 umoja gnome-shell[1429]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals conn>
The offending signal was window-added on MetaWorkspace 0x56280e5ddc70.
== Stack trace for context 0x56280cf89cd0 ==
#0 56280d051408 i resource:///org/gnome/shell/ui/init.js:21 (27e3fab70ba0 @ 48)
Nov 11 00:21:06 umoja gnome-shell[1429]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals conn>
The offending signal was window-added on MetaWorkspace 0x56281180a6b0.
== Stack trace for context 0x56280cf89cd0 ==
#0 56280d051408 i resource:///org/gnome/shell/ui/init.js:21 (27e3fab70ba0 @ 48)
Nov 11 00:21:06 umoja gnome-shell[1429]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals conn>
The offending signal was window-added on MetaWorkspace 0x56281180a6b0.
== Stack trace for context 0x56280cf89cd0 ==
#0 56280d051408 i resource:///org/gnome/shell/ui/init.js:21 (27e3fab70ba0 @ 48)
Nov 11 00:21:06 umoja gnome-shell[1429]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals conn>
The offending signal was window-added on MetaWorkspace 0x56281180a6b0.
== Stack trace for context 0x56280cf89cd0 ==
#0 56280d051408 i resource:///org/gnome/shell/ui/init.js:21 (27e3fab70ba0 @ 48)
Nov 11 00:21:06 umoja gnome-shell[1429]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals conn>
The offending signal was window-added on MetaWorkspace 0x56281180a6b0.
== Stack trace for context 0x56280cf89cd0 ==
#0 56280d051408 i resource:///org/gnome/shell/ui/init.js:21 (27e3fab70ba0 @ 48)
Nov 11 00:21:06 umoja gnome-shell[1429]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals conn>
The offending signal was size-changed on ShellWM 0x56280d2d3500.
== Stack trace for context 0x56280cf89cd0 ==
#0 56280d051408 i resource:///org/gnome/shell/ui/init.js:21 (27e3fab70ba0 @ 48)
Nov 11 00:21:06 umoja gnome-shell[1429]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals conn>
The offending signal was window-left-monitor on MetaDisplay 0x56280d7969d0.
== Stack trace for context 0x56280cf89cd0 ==
#0 56280d051408 i resource:///org/gnome/shell/ui/init.js:21 (27e3fab70ba0 @ 48)
Nov 11 00:21:06 umoja gnome-shell[1429]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals conn>
The offending signal was window-left-monitor on MetaDisplay 0x56280d7969d0.
== Stack trace for context 0x56280cf89cd0 ==
#0 56280d051408 i resource:///org/gnome/shell/ui/init.js:21 (27e3fab70ba0 @ 48)
Nov 11 00:21:06 umoja gnome-shell[1429]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals conn>
The offending signal was window-left-monitor on MetaDisplay 0x56280d7969d0.
== Stack trace for context 0x56280cf89cd0 ==
#0 56280d051408 i resource:///org/gnome/shell/ui/init.js:21 (27e3fab70ba0 @ 48)
Nov 11 00:21:06 umoja gnome-shell[1429]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals conn>
The offending signal was window-left-monitor on MetaDisplay 0x56280d7969d0.
== Stack trace for context 0x56280cf89cd0 ==
#0 56280d051408 i resource:///org/gnome/shell/ui/init.js:21 (27e3fab70ba0 @ 48)
And then it goes on and on with many more identical messages about "offending signal was window-left-monitor".