gnome-shell seems to hang on monitor disconnect, killing gnome-shell process helps to bring system to life
This bug report will be marked for expiration in 24 days if no further activity occurs. (find out why)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gnome-shell (Ubuntu) |
Incomplete
|
Undecided
|
Unassigned |
Bug Description
As title says: sometimes when I disconnect my laptop from DisplayPort-
The only relevant part I've found out is this part of the log. It's an extremely long thread of similar but mixed messages like:
```
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: == Stack trace for context 0x641018d41170 ==
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
июл 31 15:31:02 MUNIT-517 gnome-shell[3683]: The offending signal was window-
```
...and there are really a lot of those!
I've did a small count over today's bug and here are the summaries:
```
85000 == Stack trace for context 0x641018d41170 ==
29999 Attempting to run a JS callback during garbage collection. This is most likely caused by destroying a Clutter actor or GTK widget with ::destroy signal connected, or using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked.
29998 The offending callback was SourceFunc().
12501 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 connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
2680 The offending signal was window-left-monitor on MetaDisplay 0x641018e6a160.
2320 The offending signal was window-
...
```
Looks scary! Text log of gnome-shell (as captured by journalctl via systemd --user) is around 26MB.
ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: gnome-shell 42.9-0ubuntu2.1
ProcVersionSign
Uname: Linux 6.5.0-45-generic x86_64
NonfreeKernelMo
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
CasperMD5CheckR
CurrentDesktop: ubuntu:GNOME
Date: Wed Jul 31 17:37:18 2024
DisplayManager: gdm3
InstallationDate: Installed on 2022-04-19 (834 days ago)
InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819)
RelatedPackageV
SourcePackage: gnome-shell
UpgradeStatus: Upgraded to jammy on 2022-08-21 (709 days ago)
Thanks for the bug report.
I don't think the above log messages are relevant to the main problem here. Please start by removing all local extensions:
cd ~/.local/ share/gnome- shell/
rm -rf extensions
and then log in again. If the problem continues to happen then next time it does, after bringing the machine back to life (without rebooting), please run:
journalctl -b0 > journal.txt
and attach the resulting text file here.