Pop Shell completely locks up regularly at random and spams logfile until drive full

(1) Issue/Bug Description:

Desktop environment locks up with only cursor moving, seemingly at complete random intervals. Sometimes once in a few days, sometimes multiple times in an hour.

journalctl gets an initial dump of the following

"Mar 26 00:56:51 user gnome-shell[1581]: == Stack trace for context 0x558729fc5130 == Mar 26 00:56:51 user gnome-shell[1581]: #0 7ffc9d09fb30 I resource:///org/gnome/gjs/modules/core/_common.js:35 (3a601f7ba330 @ 70) Mar 26 00:56:51 user gnome-shell[1581]: #1 7ffc9d0a05d0 I /usr/share/gnome-shell/extensions/cosmic-dock@system76.com/appIcons.js:292 (18fb197dfd80 @ 55) Mar 26 00:56:51 user gnome-shell[1581]: #2 7ffc9d0a0610 I /usr/share/gnome-shell/extensions/cosmic-dock@system76.com/appIcons.js:863 (18fb197df1a0 @ 12) Mar 26 00:56:51 user gnome-shell[1581]: #3 7ffc9d0a2350 I resource:///org/gnome/shell/ui/closeDialog.js:208 (244816950470 @ 41) Mar 26 00:56:51 user gnome-shell[1581]: #4 7ffc9d0a3680 I /usr/share/gnome-shell/extensions/pop-shell@system76.com/window.js:468 (e1a86fb3c40 @ 110) Mar 26 00:56:51 user gnome-shell[1581]: #5 7ffc9d0a3700 I /usr/share/gnome-shell/extensions/pop-shell@system76.com/window.js:77 (e1a86fb8e70 @ 82) Mar 26 00:56:51 user gnome-shell[1581]: #6 7ffc9d0a3700 I /usr/share/gnome-shell/extensions/pop-shell@system76.com/extension.js:1472 (e1a86f8df10 @ 659) Mar 26 00:56:51 user gnome-shell[1581]: #7 7ffc9d0a3750 I /usr/share/gnome-shell/extensions/pop-shell@system76.com/extension.js:150 (e1a86f906f0 @ 55) Mar 26 00:56:51 user gnome-shell[1581]: #8 7ffc9d0a37b0 I /usr/share/gnome-shell/extensions/pop-shell@system76.com/executor.js:29 (e1a86fb9a10 @ 74)"

Then it gets

"Mar 26 00:56:51 user gnome-shell[1581]: The offending signal was notify on MetaDisplay 0x55872a1d8000. Mar 26 00:56:51 user gnome-shell[1581]: 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+ widge> Mar 26 00:56:51 user gnome-shell[1581]: The offending signal was notify on MetaDisplay 0x55872a1d8000. Mar 26 00:56:51 user gnome-shell[1581]: 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+ widge> Mar 26 00:56:51 user gnome-shell[1581]: The offending signal was notify on MetaDisplay 0x55872a1d8000. Mar 26 00:56:51 user gnome-shell[1581]: 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+ widge> Mar 26 00:56:51 user gnome-shell[1581]: The offending signal was notify on MetaDisplay 0x55872a1d8000. Mar 26 00:56:51 user gnome-shell[1581]: 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+ widge> Mar 26 00:56:51 user gnome-shell[1581]: The offending signal was notify on MetaStage 0x558729ed7310. Mar 26 00:56:51 user gnome-shell[1581]: 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+ widge> Mar 26 00:56:51 user gnome-shell[1581]: The offending signal was notify on MetaStage 0x558729ed7310. Mar 26 00:56:51 user gnome-shell[1581]: 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+ widge> Mar 26 00:56:51 user gnome-shell[1581]: The offending signal was raised on MetaWindowX11 0x55872bd76f50. Mar 26 00:56:51 user gnome-shell[1581]: 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+ widge> Mar 26 00:56:51 user gnome-shell[1581]: The offending signal was handle-method-call on GjsDBusImplementation 0x55872b0401c0. Mar 26 00:56:51 user gnome-shell[1581]: 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+ widge> Mar 26 00:56:51 user gnome-shell[1581]: The offending signal was notify on MetaStage 0x558729ed7310. Mar 26 00:56:51 user gnome-shell[1581]: 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+ widge> Mar 26 00:56:51 user gnome-shell[1581]: The offending signal was notify on MetaStage 0x558729ed7310. Mar 26 00:56:51 user gnome-shell[1581]: 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+ widge> Mar 26 00:56:51 user gnome-shell[1581]: The offending signal was notify on MetaStage 0x558729ed7310. Mar 26 00:56:51 user gnome-shell[1581]: 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+ widge> Mar 26 00:56:51 user gnome-shell[1581]: The offending signal was notify on MetaStage 0x558729ed7310. Mar 26 00:56:51 user gnome-shell[1581]: Attempting to run a JS callback during garbage collection. This is most likely caused by destroying a Clutter actor or GTK widget with ::destr> Mar 26 00:56:51 user gnome-shell[1581]: The offending callback was SourceFunc(). "

followed by huge repeated blocks of

"Mar 26 00:56:51 user gnome-shell[1581]: == Stack trace for context 0x558729fc5130 =="

and

"Mar 26 00:56:51 user gnome-shell[1581]: Attempting to run a JS callback during garbage collection. This is most likely caused by destroying a Clutter actor or GTK widget with ::destr> Mar 26 00:56:51 user gnome-shell[1581]: The offending callback was SourceFunc()."

until the log file/drive is full.

Only solution is a hard reboot.

(2) Steps to reproduce (if you know):

Use the computer and just wait.

(3) Expected behavior:

A computer that doesnt randomly lock up and render itself utterly unusable.

(4) Distribution (run cat /etc/os-release):

21.10

(5) Gnome Shell version:

Whatever 21.10 comes with

(6) Pop Shell version (run apt policy pop-shell or provide the latest commit if building locally):

1.1.0~1646843863~21.10~396b2f3

(7) Where was Pop Shell installed from:

The original installation.

(8) Monitor Setup (2 x 1080p, 4K, Primary(Horizontal), Secondary(Vertical), etc):

Multiple (Dell XPS 15, Thelio, Lemure, miix 520, compaq elite 8300 - EVERYTHING)

(9) Other Installed/Enabled Extensions:

Only what Pop installs for itself

(10) Other Notes:

This never happened until upgrading to 21.10 and has pretty much rendered ALL my System76/Pop machines unusable in any business related capacity. Its a massive letdown and I'd appreciate a quick response.

Your backtrace comes from cosmic-dock, so I'll need to transfer it there.

What applications do you have running that's causing this?

What applications do you have running that's causing this?

Thanks - and its honestly hard to say. Sometimes its firefox, sometimes literally just browsing files, fiddling in terminal, and in one instance, while looking at journalctl trying to figure out what cause the LAST lock. I cant discern a pattern.

Would a more complete logfile be useful? I can try upload/paste it if so

Your backtrace comes from cosmic-dock, so I'll need to transfer it there.

For my own education, what do you mean by this? Did I post this in the wrong place? Whats a 'backtrace'?

There must be a specific window causing it, because I've never had this happen before. What is above the Stack trace line?

There must be a specific window causing it, because I've never had this happen before. What is above the Stack trace line?

"Mar 26 00:52:21 user gnome-shell[1581]: Can't update stage views actor MetaSurfaceActorX11 is on because it needs an allocation. Mar 26 00:52:29 user dbus-daemon[1360]: [session uid=1000 pid=1360] Activating service name='org.gnome.gedit' requested by ':1.143' (uid=1000 pid=39202 comm="file-roller /home/paperw> Mar 26 00:52:29 user dbus-daemon[1360]: [session uid=1000 pid=1360] Successfully activated service 'org.gnome.gedit' Mar 26 00:52:29 user gnome-shell[1581]: Can't update stage views actor MetaWindowGroup is on because it needs an allocation. Mar 26 00:52:29 user gnome-shell[1581]: Can't update stage views actor MetaWindowActorX11 is on because it needs an allocation. Mar 26 00:52:29 user gnome-shell[1581]: Can't update stage views actor MetaSurfaceActorX11 is on because it needs an allocation. Mar 26 00:52:31 user gnome-shell[1581]: Can't update stage views actor MetaWindowGroup is on because it needs an allocation. Mar 26 00:52:31 user gnome-shell[1581]: Can't update stage views actor MetaWindowActorX11 is on because it needs an allocation. Mar 26 00:52:31 user gnome-shell[1581]: Can't update stage views actor MetaSurfaceActorX11 is on because it needs an allocation. Mar 26 00:52:42 user gnome-shell[1581]: Can't update stage views actor MetaWindowGroup is on because it needs an allocation. Mar 26 00:52:42 user gnome-shell[1581]: Can't update stage views actor MetaWindowActorX11 is on because it needs an allocation. Mar 26 00:52:42 user gnome-shell[1581]: Can't update stage views actor MetaSurfaceActorX11 is on because it needs an allocation. Mar 26 00:52:44 user gnome-shell[1581]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x420003e Mar 26 00:52:44 user gnome-shell[1581]: Window manager warning: Overwriting existing binding of keysym 6f with keysym 6f (keycode 20). Mar 26 00:52:44 user gnome-shell[1581]: Window manager warning: last_focus_time (3472383) is greater than comparison timestamp (3472381). This most likely represents a buggy client > Mar 26 00:52:44 user gnome-shell[1581]: Window manager warning: last_user_time (3472383) is greater than comparison timestamp (3472381). This most likely represents a buggy client s> Mar 26 00:52:44 user gnome-shell[1581]: Window manager warning: 0x420003e appears to be one of the offending windows with a timestamp of 3472383. Working around... Mar 26 00:53:39 user gnome-shell[1581]: Window manager warning: Overwriting existing binding of keysym 6f with keysym 6f (keycode 20). Mar 26 00:55:20 user mullvad-vpn.desktop[1826]: [2022-03-26 00:55:20.132][verbose] GRPC Channel connectivity state changed to 2 Mar 26 00:56:06 user gnome-shell[1581]: Window manager warning: Invalid WM_TRANSIENT_FOR window 0x4c000b2 specified for 0x4c00251. Mar 26 00:56:08 user gnome-shell[1581]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x4e04678 Mar 26 00:56:22 user dbus-daemon[1360]: [session uid=1000 pid=1360] Activating service name='org.gnome.gedit' requested by ':1.116' (uid=1000 pid=13781 comm="/usr/bin/nautilus --gapp> Mar 26 00:56:22 user dbus-daemon[1360]: [session uid=1000 pid=1360] Successfully activated service 'org.gnome.gedit' Mar 26 00:56:27 user gnome-shell[1581]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x5000101 Mar 26 00:56:27 user gnome-shell[1581]: Window manager warning: Overwriting existing binding of keysym 6f with keysym 6f (keycode 20). Mar 26 00:56:42 user gnome-shell[1581]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x5000101 Mar 26 00:56:43 user /usr/libexec/gdm-x-session[1358]: [dix] EventToCore: Not implemented yet Mar 26 00:56:51 user gnome-shell[1581]: 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+ widge> Mar 26 00:56:51 user gnome-shell[1581]: == Stack trace for context 0x558729fc5130 == "

So....gedit?

From memory, when last lockup happened I had firefox, a few terminal windows and gedit and nautilus open, and Signal.

I'm not sure that it's gedit, but Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x420003e does indicate something is not behaving well with the window manager.

I'm not sure that it's gedit, but Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x420003e does indicate something is not behaving well with the window manager.

OK. What should I do to help narrow this down for you?

I'm not sure at the moment. I think it'd be best to attach full gnome-shell logs from

journalctl -b0 /usr/bin/gnome-shell > gnome-shell.log

I'm not sure at the moment. I think it'd be best to attach full gnome-shell logs from
journalctl -b0 /usr/bin/gnome-shell > gnome-shell.log

OK, this could be difficult - the spam after the crash means the logfile is several GB now.

I could try and copy paste a larger segment covering the area of known crashes (I have a few timeslots written down)

Re the 'buggy client' message - looking closer this seems to be occuring ever time I use a touchpad gesture - I have modified touchegg from the normal dbus thingys to just use keyboard shortcuts to change workspaces, as this is part of a larger workaround for an issue i was having with the normal COSMIC setup not working properly with touchscreens.

I dont know if thats related but I can use those gestures normally without it locking up, so they dont seem related. I've also had lockups on other machines where these settings arent changed and there isnt even any touchpad/screen to use gestures in the first place, so that may be a red herring?

Let me know the best way to post the logs and I'll do what i can, thanks

Wait no, nevermind, the command you gave only ended up spitting out a small file, no idea why i took so long though.

Attached. Doesnt seem to have the same detail as journalctl tho

gnome-shell.log

Okay, well, FWIW @mmstick, I did some more digging.

I've found that those 'buggy client' window manager errors seem to be from my touchegg config file, which uses keyboard shortcuts for basically all the functionality I used to have on 20.04.

Obs so far:

-Setting touchegg to use keyboard shortcuts for ANY window-related action seems to result in these log errors when using those gestures

"Mar 26 04:16:55 user gnome-shell[1680]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x4800010 Mar 26 04:16:55 user gnome-shell[1680]: Window manager warning: Overwriting existing binding of keysym 6f with keysym 6f (keycode 20). Mar 26 04:16:55 user gnome-shell[1680]: Window manager warning: last_focus_time (11877224) is greater than comparison timestamp (11877221). This most likely represents a buggy clien> Mar 26 04:16:55 user gnome-shell[1680]: Window manager warning: last_user_time (11877224) is greater than comparison timestamp (11877221). This most likely represents a buggy client> Mar 26 04:16:55 user gnome-shell[1680]: Window manager warning: 0x4800010 appears to be one of the offending windows with a timestamp of 11877224. Working around... Mar 26 04:16:59 user gnome-shell[1680]: Window manager warning: Overwriting existing binding of keysym 6f with keysym 6f (keycode 20). "

-Killing touchegg entirely, gestures obviously are gone, but touchSCREEN gestures like 4-finger workspace change still work**, and very smoothly too I might add! You get new error s in the logs:

"Mar 26 04:22:48 user gnome-shell[1680]: Window manager warning: last_focus_time (12230896) is greater than comparison timestamp (12230880). This most likely represents a buggy clien> Mar 26 04:22:49 user gnome-shell[1680]: Window manager warning: META_CURRENT_TIME used to choose focus window; focus window may not be correct."

-Going back to the default touchegg config file, gestures start working again on both touchpad and screen, but with a different set of errors:

These when you use the touchscreen: "Mar 26 04:25:44 paperweight gnome-shell[1680]: Window manager warning: META_CURRENT_TIME used to choose focus window; focus window may not be correct. Mar 26 04:25:44 user /usr/libexec/gdm-x-session[1457]: (II) modeset(0): EDID vendor "SHP", prod id 5182 Mar 26 04:25:44 user /usr/libexec/gdm-x-session[1457]: (II) modeset(0): Printing DDC gathered Modelines: Mar 26 04:25:44 user /usr/libexec/gdm-x-session[1457]: (II) modeset(0): Modeline "3840x2160"x0.0 533.25 3840 3888 3920 4000 2160 2163 2168 2222 -hsync -vsync (133.3 kHz eP)"

These when you use touchpad:

"Mar 26 04:26:08 user gnome-shell[1680]: Window manager warning: META_CURRENT_TIME used to choose focus window; focus window may not be correct."

SO - I have no idea at all if this is whats causing the lockups, but I'm going to try ditching the keyboard-shortcut based touchegg conf file for now and see if that changes anything, and if not, I'll then try killing touchegg entirely ad see what that does.

**Side note - I've raised these gesture conflicts before in https://github.com/pop-os/cosmic/issues/293. The stock Pop touchegg/COSMIC/Pop shell extension mishmash has some really odd behavior on touchscreens, in that there seems to be multiple 'layers' of built in Pop and GNOME touchscreen gestures interfering with / working on top of Touchegg (as can be seen from the fact that workspace gestures still work with touchegg disabled). It's been a real headache getting thing working the way they used to work just fine on 20.04 - especially with COSMIC changing things that didn't need to be changed - hence the need for a touchegg config file using keyboard shortcuts.

In any case go update that issue separately later but this needs to be looked at too, I think - especially if trying to work around it is whats causing the whole system to lock up.

I'm having a bunch of issues on my system as well, and searching for error messages I'm seeing led me to this bug report. I'm experiencing the same error (but also others).

Quick question, which will help me understand if there's a link between what I'm troubleshooting and this. Are you using Flatpaks? Also, are you utilizing Fuse mounts of any kind?

I'm having a bunch of issues on my system as well, and searching for error messages I'm seeing led me to this bug report. I'm experiencing the same error (but also others).

Quick question, which will help me understand if there's a link between what I'm troubleshooting and this. Are you using Flatpaks? Also, are you utilizing Fuse mounts of any kind?

@LearnLinuxTV Sorry for the slow reply, for some reason I stopped getting email notifications for this...

To answer your question - these logs came from totally stock installations. I did use CIFS mounts and installed a couple of flatpaks in later attempts to get something workable running, but the logs above, and the crashes themselves, occurred on raw installations right out of the box.

As far as I can tell, the problem is all the hacky extensions Pop implements for their UI. Disabling them stopped the crashes, but them introduced a stack of OTHER problems. I tried moving to a new DE, which was its own nightmare and by that point ...why even use Pop?

Sorry I can't help more but with the poor outcomes I've had engaging the devs with other issues, I've since ditched Pop entirely and, for the first time in a decide, gone back to using Windows on the thelio for daily use, bizarrely enough just to have something reliable. Pop was great until a year or so a go, but now it's riddled with bugs and has a toxic dev body that is more interested in making excuses and dismissing or belittling customers than solving demonstrable problems. If you have time I'd suggest trying Manjaro if you want something that at least runs - this particular problem at least wasn't present when I tried that. and people are far more helpful.

I didn't read the whole thread, but I sometimes, the gnome lock screen locks up (...I understand the irony...), mainly right after wake from sleep. I can switch to another tty, login and kill gnome-shell which uses 100% CPU at that time.

Today I found out that my syslog had 67 GB and it's full of these:

May  3 21:05:02 pop-os systemd[1]: run-docker-runtime\x2drunc-moby-3d07cacf87c69128d593f7664341cc2df2314e47dd1e90c438a1df225dab1b98-runc.GgHIwC.mount: Deactivated successfully.
May  3 21:05:03 pop-os /usr/libexec/gdm-x-session[3648]: (II) event8  - ROCCAT ROCCAT Kone Aimo 16K Mouse: SYN_DROPPED event - some input events have been lost.
May  3 21:05:03 pop-os gsd-media-keys[4656]: gvc_mixer_card_get_index: assertion 'GVC_IS_MIXER_CARD (card)' failed
May  3 21:05:03 pop-os gsd-media-keys[4656]: gvc_mixer_card_get_index: assertion 'GVC_IS_MIXER_CARD (card)' failed
May  3 21:05:03 pop-os gnome-shell[4379]: gvc_mixer_card_get_index: assertion 'GVC_IS_MIXER_CARD (card)' failed
May  3 21:05:04 pop-os gnome-shell[4379]: JS ERROR: Failed to initialize fprintd service: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name net.reactivated.Fprint was not provided by any .service files#012a
syncCallback@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:114:23
May  3 21:05:05 pop-os gnome-shell[4379]: (../clutter/clutter/clutter-actor.c:12430):clutter_actor_event: runtime check failed: (retval == CLUTTER_EVENT_PROPAGATE)
May  3 21:05:05 pop-os gnome-shell[4379]: message repeated 3 times: [ (../clutter/clutter/clutter-actor.c:12430):clutter_actor_event: runtime check failed: (retval == CLUTTER_EVENT_PROPAGATE)]
May  3 21:05:07 pop-os gnome-shell[4379]: Object Gdm.UserVerifierProxy (0x5600cf65c150), has been already disposed — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
May  3 21:05:07 pop-os gnome-shell[4379]: == Stack trace for context 0x5600cf49d190 ==
May  3 21:05:07 pop-os gnome-shell[4379]: #0   7ffc329f0f70 b   resource:///org/gnome/gjs/modules/core/overrides/Gio.js:425 (3659e2cde70 @ 77)
May  3 21:05:07 pop-os kernel: [164333.401545] usb 1-4: new full-speed USB device number 111 using xhci_hcd
May  3 21:05:07 pop-os gnome-shell[4379]: (../clutter/clutter/clutter-actor.c:12430):clutter_actor_event: runtime check failed: (retval == CLUTTER_EVENT_PROPAGATE)
May  3 21:05:08 pop-os gnome-shell[4379]: message repeated 3 times: [ (../clutter/clutter/clutter-actor.c:12430):clutter_actor_event: runtime check failed: (retval == CLUTTER_EVENT_PROPAGATE)]
May  3 21:05:08 pop-os gnome-shell[4379]: 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.
May  3 21:05:08 pop-os gnome-shell[4379]: == Stack trace for context 0x5600cf49d190 ==
May  3 21:05:08 pop-os gnome-shell[4379]: message repeated 26 times: [ == Stack trace for context 0x5600cf49d190 ==]
May  3 21:05:08 pop-os gnome-shell[4379]: The offending signal was notify on MetaStage 0x5600cf42b160.
May  3 21:05:08 pop-os gnome-shell[4379]: == Stack trace for context 0x5600cf49d190 ==
May  3 21:05:08 pop-os gnome-shell[4379]: message repeated 44 times: [ == Stack trace for context 0x5600cf49d190 ==]
May  3 21:05:08 pop-os gnome-shell[4379]: 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.
May  3 21:05:08 pop-os gnome-shell[4379]: == Stack trace for context 0x5600cf49d190 ==
May  3 21:05:08 pop-os gnome-shell[4379]: message repeated 31 times: [ == Stack trace for context 0x5600cf49d190 ==]
May  3 21:05:08 pop-os gnome-shell[4379]: The offending signal was notify on MetaStage 0x5600cf42b160.
May  3 21:05:08 pop-os gnome-shell[4379]: 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.
May  3 21:05:08 pop-os gnome-shell[4379]: The offending signal was notify on MetaStage 0x5600cf42b160.

# skipped a few of these, continuing...

May  3 21:05:08 pop-os gnome-shell[4379]: 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.
May  3 21:05:08 pop-os gnome-shell[4379]: The offending signal was notify on MetaStage 0x5600cf42b160.
May  3 21:05:08 pop-os gnome-shell[4379]: == Stack trace for context 0x5600cf49d190 ==
May  3 21:05:08 pop-os gnome-shell[4379]: message repeated 10 times: [ == Stack trace for context 0x5600cf49d190 ==]
May  3 21:05:08 pop-os gnome-shell[4379]: 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.
May  3 21:05:08 pop-os gnome-shell[4379]: == Stack trace for context 0x5600cf49d190 ==
May  3 21:05:08 pop-os gnome-shell[4379]: message repeated 44 times: [ == Stack trace for context 0x5600cf49d190 ==]
May  3 21:05:08 pop-os gnome-shell[4379]: The offending signal was notify on MetaStage 0x5600cf42b160.
May  3 21:05:08 pop-os gnome-shell[4379]: == Stack trace for context 0x5600cf49d190 ==
May  3 21:05:08 pop-os gnome-shell[4379]: message repeated 23 times: [ == Stack trace for context 0x5600cf49d190 ==]
May  3 21:05:08 pop-os gnome-shell[4379]: 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.
May  3 21:05:08 pop-os gnome-shell[4379]: The offending signal was notify on MetaStage 0x5600cf42b160.

# [... skipped 20 MB of these above; the message changed slightly...]

May  3 21:05:10 pop-os gnome-shell[4379]: The offending callback was SourceFunc().
May  3 21:05:10 pop-os gnome-shell[4379]: == Stack trace for context 0x5600cf49d190 ==
May  3 21:05:10 pop-os gnome-shell[4379]: 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(), dispos
e(), or remove() vfuncs. Because it would crash the application, it has been blocked.
May  3 21:05:10 pop-os gnome-shell[4379]: The offending callback was SourceFunc().
May  3 21:05:10 pop-os gnome-shell[4379]: == Stack trace for context 0x5600cf49d190 ==
May  3 21:05:10 pop-os gnome-shell[4379]: 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(), dispos
e(), or remove() vfuncs. Because it would crash the application, it has been blocked.
May  3 21:05:10 pop-os gnome-shell[4379]: The offending callback was SourceFunc().
May  3 21:05:10 pop-os gnome-shell[4379]: == Stack trace for context 0x5600cf49d190 ==
May  3 21:05:10 pop-os gnome-shell[4379]: 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(), dispos
e(), or remove() vfuncs. Because it would crash the application, it has been blocked.
May  3 21:05:10 pop-os gnome-shell[4379]: The offending callback was SourceFunc().
May  3 21:05:10 pop-os gnome-shell[4379]: == Stack trace for context 0x5600cf49d190 ==

# [...another gigabytes of these...]

Currently running latest PopOS 22.04, but the hard lock on gnome lock screen was happening for me in 20.10, too. Don't know if the error messages were the same. Sometimes I couldn't even switch to another tty and had to hard reset. Sorry I can't give more specific information, I'll let you know when this happens again.

According to apt/history.log, I was using pop-shell 1.1.0~1649099191~22.04~cb76a4c at the time of these logs.

NAME="Pop!_OS"
VERSION="22.04 LTS"

Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz NVIDIA GeForce 2080 with nvidia-driver-460 470.86-1pop0~1650323395~22.04~5bc8ef6 (at the time of the logs above)

Also starting to get large Syslog since upgrading from 20.04

Here are some of the heavy hitters that I see spamming me in the journal

May 09 19:10:41 pop-os gnome-shell[477148]: DING: (gjs:1401718): GLib-CRITICAL **: 19:10:41.494: Failed to set scheduler settings: Operation not permitted
May 09 19:11:41 pop-os gnome-shell[477148]: DING: (gjs:1401843): GLib-CRITICAL **: 19:11:41.470: Failed to set scheduler settings: Operation not permitted
May 09 19:12:41 pop-os gnome-shell[477148]: DING: (gjs:1401979): GLib-CRITICAL **: 19:12:41.496: Failed to set scheduler settings: Operation not permitted
May 09 19:13:41 pop-os gnome-shell[477148]: DING: (gjs:1402108): GLib-CRITICAL **: 19:13:41.454: Failed to set scheduler settings: Operation not permitted
May 09 19:14:41 pop-os gnome-shell[477148]: DING: (gjs:1402246): GLib-CRITICAL **: 19:14:41.455: Failed to set scheduler settings: Operation not permitted
May 09 19:15:41 pop-os gnome-shell[477148]: DING: (gjs:1402374): GLib-CRITICAL **: 19:15:41.460: Failed to set scheduler settings: Operation not permitted
May 09 19:16:41 pop-os gnome-shell[477148]: DING: (gjs:1402497): GLib-CRITICAL **: 19:16:41.495: Failed to set scheduler settings: Operation not permitted
May 09 19:17:41 pop-os gnome-shell[477148]: DING: (gjs:1402643): GLib-CRITICAL **: 19:17:41.464: Failed to set scheduler settings: Operation not permitted
May 09 19:18:41 pop-os gnome-shell[477148]: DING: (gjs:1402768): GLib-CRITICAL **: 19:18:41.494: Failed to set scheduler settings: Operation not permitted
May 09 19:19:41 pop-os gnome-shell[477148]: DING: (gjs:1402896): GLib-CRITICAL **: 19:19:41.495: Failed to set scheduler settings: Operation not permitted
May 09 19:20:41 pop-os gnome-shell[477148]: DING: (gjs:1403023): GLib-CRITICAL **: 19:20:41.496: Failed to set scheduler settings: Operation not permitted
May 09 19:21:41 pop-os gnome-shell[477148]: DING: (gjs:1403149): GLib-CRITICAL **: 19:21:41.489: Failed to set scheduler settings: Operation not permitted
May 09 19:22:41 pop-os gnome-shell[477148]: DING: (gjs:1403292): GLib-CRITICAL **: 19:22:41.493: Failed to set scheduler settings: Operation not permitted
May 09 19:23:41 pop-os gnome-shell[477148]: DING: (gjs:1403422): GLib-CRITICAL **: 19:23:41.496: Failed to set scheduler settings: Operation not permitted
May 09 19:24:41 pop-os gnome-shell[477148]: DING: (gjs:1403560): GLib-CRITICAL **: 19:24:41.489: Failed to set scheduler settings: Operation not permitted
May 09 19:25:41 pop-os gnome-shell[477148]: DING: (gjs:1403684): GLib-CRITICAL **: 19:25:41.458: Failed to set scheduler settings: Operation not permitted
May 09 19:26:41 pop-os gnome-shell[477148]: DING: (gjs:1403818): GLib-CRITICAL **: 19:26:41.477: Failed to set scheduler settings: Operation not permitted
May 09 19:27:41 pop-os gnome-shell[477148]: DING: (gjs:1404533): GLib-CRITICAL **: 19:27:41.495: Failed to set scheduler settings: Operation not permitted
May 09 19:28:41 pop-os gnome-shell[477148]: DING: (gjs:1406525): GLib-CRITICAL **: 19:28:41.494: Failed to set scheduler settings: Operation not permitted
May 09 19:29:41 pop-os gnome-shell[477148]: DING: (gjs:1406760): GLib-CRITICAL **: 19:29:41.470: Failed to set scheduler settings: Operation not permitted
May 09 19:30:41 pop-os gnome-shell[477148]: DING: (gjs:1406985): GLib-CRITICAL **: 19:30:41.494: Failed to set scheduler settings: Operation not permitted
May 09 19:31:41 pop-os gnome-shell[477148]: DING: (gjs:1407234): GLib-CRITICAL **: 19:31:41.496: Failed to set scheduler settings: Operation not permitted
May 09 19:32:41 pop-os gnome-shell[477148]: DING: (gjs:1407538): GLib-CRITICAL **: 19:32:41.486: Failed to set scheduler settings: Operation not permitted
May 09 19:33:41 pop-os gnome-shell[477148]: DING: (gjs:1407703): GLib-CRITICAL **: 19:33:41.496: Failed to set scheduler settings: Operation not permitted
May 09 19:34:41 pop-os gnome-shell[477148]: DING: (gjs:1407829): GLib-CRITICAL **: 19:34:41.476: Failed to set scheduler settings: Operation not permitted
May 09 19:35:41 pop-os gnome-shell[477148]: DING: (gjs:1408030): GLib-CRITICAL **: 19:35:41.484: Failed to set scheduler settings: Operation not permitted
May 09 19:36:41 pop-os gnome-shell[477148]: DING: (gjs:1408255): GLib-CRITICAL **: 19:36:41.495: Failed to set scheduler settings: Operation not permitted
May 09 19:37:41 pop-os gnome-shell[477148]: DING: (gjs:1408480): GLib-CRITICAL **: 19:37:41.478: Failed to set scheduler settings: Operation not permitted
May 09 19:38:41 pop-os gnome-shell[477148]: DING: (gjs:1408858): GLib-CRITICAL **: 19:38:41.468: Failed to set scheduler settings: Operation not permitted
May 09 19:39:41 pop-os gnome-shell[477148]: DING: (gjs:1408996): GLib-CRITICAL **: 19:39:41.454: Failed to set scheduler settings: Operation not permitted
May 09 19:40:41 pop-os gnome-shell[477148]: DING: (gjs:1409126): GLib-CRITICAL **: 19:40:41.452: Failed to set scheduler settings: Operation not permitted
May 09 19:41:41 pop-os gnome-shell[477148]: DING: (gjs:1409414): GLib-CRITICAL **: 19:41:41.496: Failed to set scheduler settings: Operation not permitted
May 09 19:42:41 pop-os gnome-shell[477148]: DING: (gjs:1409621): GLib-CRITICAL **: 19:42:41.454: Failed to set scheduler settings: Operation not permitted

May 09 13:05:10 pop-os gnome-shell[477148]: cogl_framebuffer_set_viewport: assertion 'width > 0 && height > 0' failed
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<Gjs_ui_overviewControls_ControlsManager>:0x559a333783a0] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<Gjs_ui_workspacesView_WorkspacesDisplay>:0x559a32bf25d0] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<Gjs_ui_workspacesView_WorkspacesView>:0x559a522dc620] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<Gjs_ui_workspace_Workspace>:0x559a5237aa60] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<ClutterActor>:0x559a4545fc00] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<Gjs_ui_windowPreview_WindowPreview>:0x559a4b74b950] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<StLabel>:0x559a56e3af90] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<ClutterText>:0x559a56ee6c40] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<StButton>:0x559a56dfe3b0] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<StIcon>:0x559a529437b0] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<ClutterActor>:0x559a52194ff0] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<Gjs_ui_windowPreview_WindowPreview>:0x559a52899e20] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<StLabel>:0x559a4b68b290] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<ClutterText>:0x559a5237ceb0] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<StButton>:0x559a52962860] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<StIcon>:0x559a56fe9480] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<ClutterActor>:0x559a44192370] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: cogl_framebuffer_set_viewport: assertion 'width > 0 && height > 0' failed
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<Gjs_ui_overviewControls_ControlsManager>:0x559a333783a0] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<Gjs_ui_workspacesView_WorkspacesDisplay>:0x559a32bf25d0] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<Gjs_ui_workspacesView_WorkspacesView>:0x559a522dc620] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<Gjs_ui_workspace_Workspace>:0x559a5237aa60] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<ClutterActor>:0x559a4545fc00] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<Gjs_ui_windowPreview_WindowPreview>:0x559a4b74b950] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<StLabel>:0x559a56e3af90] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<ClutterText>:0x559a56ee6c40] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<StButton>:0x559a56dfe3b0] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<StIcon>:0x559a529437b0] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<ClutterActor>:0x559a52194ff0] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<Gjs_ui_windowPreview_WindowPreview>:0x559a52899e20] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<StLabel>:0x559a4b68b290] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<ClutterText>:0x559a5237ceb0] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<StButton>:0x559a52962860] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<StIcon>:0x559a56fe9480] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: Can't update stage views actor <unnamed>[<ClutterActor>:0x559a44192370] is on because it needs an allocation.
May 09 13:05:10 pop-os gnome-shell[477148]: cogl_framebuffer_set_viewport: assertion 'width > 0 && height > 0' failed

May 09 13:05:10 pop-os gnome-shell[477148]: The offending callback was SourceFunc().
May 09 13:05:10 pop-os gnome-shell[477148]: 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.
May 09 13:05:10 pop-os gnome-shell[477148]: The offending callback was SourceFunc().
May 09 13:05:10 pop-os gnome-shell[477148]: 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.
May 09 13:05:10 pop-os gnome-shell[477148]: The offending callback was SourceFunc().
May 09 13:05:10 pop-os gnome-shell[477148]: 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.
May 09 13:05:10 pop-os gnome-shell[477148]: The offending callback was SourceFunc().
May 09 13:05:10 pop-os gnome-shell[477148]: 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.
May 09 13:05:10 pop-os gnome-shell[477148]: The offending callback was SourceFunc().
May 09 13:05:10 pop-os gnome-shell[477148]: 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.
May 09 13:05:10 pop-os gnome-shell[477148]: The offending callback was SourceFunc().
May 09 13:05:10 pop-os gnome-shell[477148]: 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.
May 09 13:05:10 pop-os gnome-shell[477148]: The offending callback was SourceFunc().
May 09 13:05:10 pop-os gnome-shell[477148]: 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.
May 09 13:05:10 pop-os gnome-shell[477148]: The offending callback was SourceFunc().
May 09 13:05:10 pop-os gnome-shell[477148]: 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.
May 09 13:05:10 pop-os gnome-shell[477148]: The offending callback was SourceFunc().
May 09 13:05:10 pop-os gnome-shell[477148]: 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.
May 09 13:05:10 pop-os gnome-shell[477148]: The offending callback was leave_event(), a vfunc.
May 09 13:05:10 pop-os gnome-shell[477148]: 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.
May 09 13:05:10 pop-os gnome-shell[477148]: The offending callback was SourceFunc().
May 09 13:05:10 pop-os gnome-shell[477148]: 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.
May 09 13:05:10 pop-os gnome-shell[477148]: The offending callback was SourceFunc().
May 09 13:05:10 pop-os gnome-shell[477148]: 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.
May 09 13:05:10 pop-os gnome-shell[477148]: The offending callback was enter_event(), a vfunc.
May 09 13:05:10 pop-os gnome-shell[477148]: 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.
May 09 13:05:10 pop-os gnome-shell[477148]: The offending callback was SourceFunc().
May 09 13:05:10 pop-os gnome-shell[477148]: 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.
May 09 13:05:10 pop-os gnome-shell[477148]: The offending callback was SourceFunc().
May 09 13:05:10 pop-os gnome-shell[477148]: 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.
May 09 13:05:10 pop-os gnome-shell[477148]: The offending callback was SourceFunc().
May 09 13:05:10 pop-os gnome-shell[477148]: 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.
May 09 13:05:10 pop-os gnome-shell[477148]: The offending callback was SourceFunc().
May 09 13:05:10 pop-os gnome-shell[477148]: 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.
May 09 13:05:10 pop-os gnome-shell[477148]: The offending callback was leave_event(), a vfunc.
May 09 13:05:10 pop-os gnome-shell[477148]: 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.
May 09 13:05:10 pop-os gnome-shell[477148]: The offending callback was SourceFunc().
May 09 13:05:10 pop-os gnome-shell[477148]: 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.

May 09 13:05:07 pop-os gnome-shell[477148]: The offending signal was notify on MetaStage 0x559a31e45450.
May 09 13:05:07 pop-os gnome-shell[477148]: 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.
May 09 13:05:07 pop-os gnome-shell[477148]: The offending signal was notify on MetaStage 0x559a31e45450.
May 09 13:05:07 pop-os gnome-shell[477148]: 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.
May 09 13:05:07 pop-os gnome-shell[477148]: The offending signal was notify on MetaStage 0x559a31e45450.
May 09 13:05:07 pop-os gnome-shell[477148]: 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.
May 09 13:05:07 pop-os gnome-shell[477148]: The offending signal was notify on MetaStage 0x559a31e45450.
May 09 13:05:07 pop-os gnome-shell[477148]: 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.
May 09 13:05:07 pop-os gnome-shell[477148]: The offending signal was notify on MetaStage 0x559a31e45450.
May 09 13:05:07 pop-os gnome-shell[477148]: 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.
May 09 13:05:07 pop-os gnome-shell[477148]: The offending signal was notify on MetaStage 0x559a31e45450.
May 09 13:05:07 pop-os gnome-shell[477148]: 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.
May 09 13:05:07 pop-os gnome-shell[477148]: The offending signal was notify on MetaStage 0x559a31e45450.
May 09 13:05:07 pop-os gnome-shell[477148]: 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.
May 09 13:05:07 pop-os gnome-shell[477148]: The offending signal was notify on MetaStage 0x559a31e45450.
May 09 13:05:07 pop-os gnome-shell[477148]: 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.
May 09 13:05:07 pop-os gnome-shell[477148]: The offending signal was notify on MetaStage 0x559a31e45450.
May 09 13:05:07 pop-os gnome-shell[477148]: 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.
May 09 13:05:07 pop-os gnome-shell[477148]: The offending signal was notify on MetaStage 0x559a31e45450.
May 09 13:05:07 pop-os gnome-shell[477148]: 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.
May 09 13:05:07 pop-os gnome-shell[477148]: The offending signal was notify on MetaStage 0x559a31e45450.
May 09 13:05:07 pop-os gnome-shell[477148]: 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.
May 09 13:05:07 pop-os gnome-shell[477148]: The offending signal was notify on MetaStage 0x559a31e45450.
May 09 13:05:07 pop-os gnome-shell[477148]: 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.
May 09 13:05:07 pop-os gnome-shell[477148]: The offending signal was notify on MetaStage 0x559a31e45450.
May 09 13:05:07 pop-os gnome-shell[477148]: 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.
May 09 13:05:07 pop-os gnome-shell[477148]: The offending signal was notify on MetaStage 0x559a31e45450.

+1 to this. having the same issue after upgrading.

Logs from the support panel would be helpful

I've got the same problem on 22.04. Here is the log from (journalctl -b0 /usr/bin/gnome-shell > gnome-shell.log) problem starts at 19:24:xx gnome-shell.zip

I had fonts, wezterm, vscode and chrome opened at the time. Pretty clean install (just installed pop os earlier today)

Is there no movement on this issue? It is getting so bad it has made my system completely unusable and I'd really love to be able to get it functioning again. If I can provide any additional logs, info, troubleshooting, please let me know.

Is there no movement on this issue? It is getting so bad it has made my system completely unusable and I'd really love to be able to get it functioning again. If I can provide any additional logs, info, troubleshooting, please let me know.

It's Pop. If history is any indicator, unless they expect it to affect sales, they literally don't care. They're happy to completely ignore system-breaking bugs like this, in favor of developing an entirely redundant new DE - because they know the latter gets headlines. Then, once the systems start having problems, they can just switch efforts to The New Thing, and tell users to 'file a bug report' .... and then ignore it entirely, like they're doing here, and on a whole bunch of other bugs (like power management auto switching).

The solution is 'switch distro', and support a better organization.

if it helps, I had this issue regularly but it seems to have disappeared after updating popos (I've gone through at least two updates since having the issue).

Same here. I try to clear the syslog but it returned access denied with root. i needed to resize the partition just to boot. happened when I try to open a game called DJMAX on steam.

Sep 5 19:39:55 xxxxx gnome-shell[2627]: 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.
Sep 5 19:39:55 xxxxx gnome-shell[2627]: The offending signal was notify on MetaStage 0x556d2f1d4930.
Sep 5 19:39:55 xxxxx gnome-shell[2627]: == Stack trace for context 0x556d2f227180 ==
Sep 5 19:39:55 xxxxx gnome-shell[2627]: #0 7ffcb1e0fbd0 b resource:///org/gnome/shell/ui/closeDialog.js:205 (3e3ade63fb50 @ 41)
Sep 5 19:39:55 xxxxx gnome-shell[2627]: #1 7ffcb1e10c50 b /usr/share/gnome-shell/extensions/pop-shell@system76.com/window.js:503 (bd85551db50 @ 145)
Sep 5 19:39:55 xxxxx gnome-shell[2627]: #2 7ffcb1e10d50 b /usr/share/gnome-shell/extensions/pop-shell@system76.com/window.js:82 (bd85551a830 @ 91)
Sep 5 19:39:55 xxxxx gnome-shell[2627]: #3 7ffcb1e10e20 b /usr/share/gnome-shell/extensions/pop-shell@system76.com/extension.js:1557 (2d13c54f3650 @ 501)
Sep 5 19:39:55 xxxxx gnome-shell[2627]: #4 7ffcb1e10ee0 b /usr/share/gnome-shell/extensions/pop-shell@system76.com/extension.js:1582 (2d13c54f36a0 @ 374)
Sep 5 19:39:55 xxxxx gnome-shell[2627]: #5 7ffcb1e10ff0 b /usr/share/gnome-shell/extensions/pop-shell@system76.com/extension.js:156 (2d13c54dbce0 @ 55)
Sep 5 19:39:55 xxxxx gnome-shell[2627]: #6 7ffcb1e110b0 b /usr/share/gnome-shell/extensions/pop-shell@system76.com/executor.js:27 (bd85551e470 @ 79)
Sep 5 19:39:55 xxxxx gnome-shell[2627]: == Stack trace for context 0x556d2f227180 ==
... until it fills the entire disk

@rafaelhipercg It'd be helpful if you could try building and installing https://github.com/pop-os/shell/pull/1520 and checking the logs after.

+1 here.Same issue when I execute python script which opens a window to visualize images using opencv2 library.

@rafaelhipercg It'd be helpful if you could try building and installing #1520 and checking the logs after.

I don't know how to do that, sorry.

I'm having a related, if not the same issue. I'm happy to try things, if ELI5. Thanks!

System completely hangs around this time:

❯ sudo journalctl --no-hostname --since "30 days ago" | grep "JS"
...
Nov 22 07:04:08 gnome-shell[2742]: 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.
Nov 22 07:04:08 gnome-shell[2742]: 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.
Nov 22 07:06:21 gnome-shell[1509]: JS ERROR: Failed to initialize fprintd service: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
Nov 22 08:29:34 gnome-shell[2985]: JS ERROR: Failed to initialize fprintd service: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
...

Brave Browser becomes unresponsive, then usually begins working again:

❯ sudo journalctl --no-hostname --since "30 days ago" | grep -i "update stage views" | tail -5
Nov 22 12:48:30 gnome-shell[2757]: Can't update stage views actor <unnamed>[<MetaWindowGroup>:0x55f83be0c360] is on because it needs an allocation.
Nov 22 12:48:30 gnome-shell[2757]: Can't update stage views actor <unnamed>[<MetaWindowActorX11>:0x55f83e68bee0] is on because it needs an allocation.
Nov 22 12:48:30 gnome-shell[2757]: Can't update stage views actor <unnamed>[<MetaSurfaceActorX11>:0x55f83e68ede0] is on because it needs an allocation.
Nov 22 12:48:30 gnome-shell[2757]: Can't update stage views actor <unnamed>[<MetaWindowActorX11>:0x55f83e6a32f0] is on because it needs an allocation.
Nov 22 12:48:30 gnome-shell[2757]: Can't update stage views actor <unnamed>[<MetaSurfaceActorX11>:0x55f83e68f4e0] is on because it needs an allocation.
(base)

 neofetch
             /////////////                john@pop-os 
         /////////////////////            ----------- 
      ///////*767////////////////         OS: Pop!_OS 22.04 LTS x86_64 
    //////7676767676*//////////////       Host: OptiPlex 7040 
   /////76767//7676767//////////////      Kernel: 6.0.6-76060006-generic 
  /////767676///*76767///////////////     Uptime: 41 mins 
 ///////767676///76767.///7676*///////    Packages: 2192 (dpkg), 14 (brew), 39 (flatpak) 
/////////767676//76767///767676////////   Shell: zsh 5.8.1 
//////////76767676767////76767/////////   Resolution: 2560x1440 
///////////76767676//////7676//////////   DE: GNOME 42.3.1 
////////////,7676,///////767///////////   WM: Mutter 
/////////////*7676///////76////////////   WM Theme: Pop 
///////////////7676////////////////////   Theme: Pop-dark [GTK2/3] 
 ///////////////7676///767////////////    Icons: Pop [GTK2/3] 
  //////////////////////'////////////     Terminal: gnome-terminal 
   //////.7676767676767676767,//////      CPU: Intel i7-6700 (8) @ 4.000GHz 
    /////767676767676767676767/////       GPU: Intel HD Graphics 530 
      ///////////////////////////         Memory: 3733MiB / 15881MiB 
         /////////////////////
             /////////////

❯ flatpak list  
Name                        Application ID                            Version           Branch     Installation
Arduino IDE v2              cc.arduino.IDE2                           2.0.2             stable     user
Brave Browser               com.brave.Browser                         1.45.127          stable     user
spectator translations      com.github.treagod.spectator.Locale                         stable     user
Trilium Notes               com.github.zadam.trilium                  0.56.2            stable     user
...

I have this issue intermittently. BTW, I think that X is still passing input to the underlying processes, so be careful where you click and what you type.

If you can get to a shell on your machine when it is in this state (I shh from another machine), you can fix it by sending gnome-shell a SIGHUP:

$ ps -ef | grep gnome-shell
# Use the PID from the gnome-shell process
$ kill -HUP <gnome-shell-pid>

This usually fixes the issue for me and all my processes and windows are back.

If that doesn't work, trying restarting gdm:

sudo systemctl restart gdm

Taking this route will terminate your session and processes however.

Unfortunately I just had to give up on Pop_OS. Too many issues and instabilities to be able to continue with it. Now that pop-shell is available on fedora, ubuntu, etc I see no reason to stick with it. It also didn't help that outstanding issues were never addressed or responded to by the pop_os team. On the same system, I installed fedora and gnome-shell-extension-pop-shell and I have not had issues with the system or screen locking up at all. Pop_OS was a great idea but badly implemented and maintained unfortunately.

It's a bit of a stretch to go from your machine having issues, to "badly implemented and maintained" ...

If this issue doesn't stop being a giant complaint fest, I'm going to lock it. This is a bug tracker, not the place for airing grievances. Let's stay focused on the bug report at hand.

This is one of many issues that have sat without resolution for far to long. Especially something that leaves a system completely locked up and useless. I am suggesting to others what they can do to avoid those issues... drop pop-os and use pop-shell on another OS. It was a simple recommendation. Bug trackers are fine so long as there is movement on issues and is almost 9 months acceptable to have no forward progress or acceptable workarounds? Threatening to lock an issue because folks are complaining is completely counterintuitive and just validates what is wrong with pop_os and its community. Want folks to stop complaining? Lets get this fixed.

Show me how to reproduce it then. I can't do anything if I can't replicate the bug.

Starting with steps to reproduce, use cases that seem to induce the behavior, even hardware details are all things that are much more productive than telling everyone to just stop using it because it froze for you. "Locking up", "instability", "freezing" are all extremely vague descriptions that could be attributed to hundreds of things. The only thing less useful than that is commenting about how you jumped ship and spreading misinformation about how our OS is "poorly maintained."

The more this issue gets filled with stuff like that, the less useful the bug report gets. You're diluting any useful information that is in here. I'm not threatening to lock the thread because I dislike your complaints, I'm threatening to lock it because it has no use once it's devolved into nothing but grousing. Enough already.

Unfortunately, it's very difficult to diagnose the root cause of an issue in a gnome-shell extension when logs are referencing C code somewhere in gnome-shell and there's not a single reference to a line of code in pop-shell itself, or no backtrace at all.

I've seen reports of regressions in newer versions of gnome-shell affecting pop-shell, but gnome-shell maintainers aren't interested in fixing things that affect only pop-shell. So pop-shell doesn't officially support newer versions for the moment.

Some mentioned disabling animations fixes a lot of freezing in GNOME. But a lot of issues seem to be sensitive to precise timing.

Responses like this, calling my opinion and thoughts about it "misinformation", just proves my point really. Again, I simply offered others what I did which was stop using pop-os and stick with pop-shell on another OS. Please don't pretend you know where we work or what knowledge we have on open-source software Jay. I feel like we've had more comments on this issue today because I inadvertently rubbed someone the wrong way, than we've had since it was opened.

Speaking about doing the best we all can...

What can we provide you? What logs? What commands can be run? How do we reproduce "random lockups" ? I, and I am sure others, are completely willing to help in any way possible. What bugs and issues can we open in upstream projects like gnome that would help move this forward and get this resolved?

I have a system directly from system76, with pop-os installed directly from them. I'd be more than happy to re-install a stock os on it and test.

What logs? What commands can be run?

As Michael explained already, there are not always logs that contain relevant information to track down an issue. Nobody has given you any commands to run because there is not a magic "fix it" command.

How do we reproduce "random lockups" ?

I understand this kind of issue can be frustrating. There is not code in pop-shell that says "pick a random number, and if it's even, lock up." The same code runs every time, so the lockups are not actually "random." If the same sequence of events is repeated twice on a computer, then they should lead to the same result. (If they don't, then it's likely a hardware failure causing the issue; otherwise, the sequence of events was not actually identical, so there's some other software or timing component being overlooked.)

A list of steps to go from a fresh login to the issue occurring is what would definitively allow the issue to be recreated by the developers, fixed, and tested for in the future if necessary. (If we follow that list and don't see the same issue, then we would need more information about the timing of the steps, other software running on the system, the hardware you're using, etc.; for example, lockups can be graphics-related, but you have not stated what kind of GPU your system is using.) Anything short of that, and you simply need to understand that other people are not experiencing the same problem.

Deleted, the advice that was provided by me wasn’t what was desired.

@LearnLinuxTV While I think we all appreciate the sentiment, let's please not get into badmouthing GNOME unnecessarily or retaliating against negative comments. We'll lock the issue or clean up comments if that becomes necessary, but we don't need fights happening on GitHub.

I don't understand why someone would need tmux installed to use that command, nor why they need to stream syslog to a file manually instead of just using journalctl. A week is also a pretty arbitrary amount of time to ask someone to do something.

(I also want to make clear that @LearnLinuxTV is volunteering his time to help here, he is not part of the Pop!_OS organization.)

“I also want to make clear that @LearnLinuxTV is volunteering his time to help here, he is not part of the Pop!_OS organization.” That statement is correct. Or at least, it WAS correct. I’ll no longer contribute or volunteer since my input isn’t welcome. Pop!_OS is an amazing distribution and it’s in good hands so you’ll be successful regardless.

Cheers!

Alright, it can't be salvaged. We can start a new issue, but this one is locked and closed. Let's be better in the next one.

pop-os / shell

Pop Shell completely locks up regularly at random and spams logfile until drive full #1379