gnome-shell fills syslog: 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. The offending callback was SourceFunc().

This is the king of message filling up the logs:

Nov 06 16:21:40 delly gnome-shell[5259]: 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 blocke>
Nov 06 16:21:40 delly gnome-shell[5259]: The offending callback was SourceFunc().

Also note that gnome-shell takes 100% CPU

Please run this command:

  ls ~/.local/share/gnome-shell/extensions > local.txt

and then attach the resulting text file here.

bi@c2:~$ ls ~/.local/share/gnome-shell/extensions > local.txt
ls: cannot access '~/.local/share/gnome-shell/extensions': No such file or directory

The only files in folder ~/.local/share/gnome-shell/ are:

bi@c2:~$ ls ~/.local/share/gnome-shell/
application_state gnome-overrides-migrated

I can confirm the same effect for myself, Ubuntu 20.04

grep -n -m 1 '8 23:58:00' syslog.1
843618574:Jan 8 23:58:00 smallbox gnome-shell[3313]: The offending callback was SourceFunc()

$ grep -n -m 1 '8 23:59:00' syslog.1
845405757:Jan 8 23:59:00 smallbox gnome-shell[3313]: The offending callback was SourceFunc().

That is close to 1.8 Million entries per minute. Eventually the disk was full after 250GB of logs.

Background: I had in the past (also with 18.04) noticed that the UI gets very sluggish at occasions, e.g. when running qbittorrent for some days. At this time digikam (7.2beta) was running its face recognition (I allowed all CPUs) using 70-90% CPU. There is a high amount of disk I/O. Initially that caused no significant impact on the usage. After about 5 hours, the UI got sluggish, after 24h it became unbearable to click from one window to another. I disabled the screenlock (logging in took about 2 min by now). At about 14:45 waking up the screen, displayed the favorites bar plus the big clock (frozen) on fuzzy background, a login field did not appear.

Hoping at least digikam would finish, I left it until the next morning. After a power-off and some hassles of clearing disk space, I had working machine again. I have attached an extract of the syslog from around 14:45 when things went bad. If of interest, I still have the full syslogs and can find bits in there.

I saw a similar issue here: https://github.com/GSConnect/gnome-shell-extension-gsconnect/issues/588, but I don't have gsconnect installed

In addition to my previous entry (I can't seem to edit it), I'd like to say the "unbearable" switching from window to window means 5-15 seconds.

For me, this flood of errors appears as the end result of something else taking place. For me, that only started after the observed drastic sluggishness of the UI. That had happened before, though I didn't check any logs. Actually with qbittorrent, there was no obvious high system load, and digikam did perform well in the background (memory usage also no more than 60-70%) as the progress showed (up to 14:45)

If anyone has any hints about how to reproduce the bug then please mention them upstream in:

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1868

I bumped into the same: disk full.

After inspection:
/var/log/syslog 20GB
/var/log/syslog.1 60GB

... removing /var/log/syslog.1 same some disk space free, but /var/log/syslog keep on growing, so I'm going to reboot.

Jan 16 08:57:24 brixit gnome-shell[1788]: The offending callback was SourceFunc().
Jan 16 08:57:24 brixit gnome-shell[1788]: 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.

Hint from another user:
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1868#note_1050922
@ogra

Disk full today! Same error messages

syslog.* files about 30-40GB

I'm having this problem on a machine that uses google chrome, the gnome calculator and a corporate software. It's vanilla Ubuntu 20.04.

Syslog reaches 50g and the machine stops working (disk full). Exact same message as reported.

Any way to stop the log until the problem is resolved?

gnome-shell: 3.36.7-0ubuntu0.20.04.1
google-chrome-stable: 90.0.4430.93-1

Hi everyone,

I have the same problem. The solution to avoid the log flooding the entire disk is to place this line in the root cron (sudo crontab -e):
*/1 * * * * [[ $(tail /mnt/data/system/var/log/syslog | grep -vi "cron" | grep "The offending callback was SourceFunc().") ]] && kill -HUP $(pidof gnome-shell)

This greps the last lines of the log every minute and triggers a restart of gnome-shell if the offending callback is found. None of the current applications are killed (except gnome-shell) which is convenient. If you are limited in space, I would recommend to run the command every 30s or less. Source of this is available here: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1868#note_1050922

Hope this helps.

EDIT: By the way, here are information related to my system:
- Ubuntu 20.04.2
- 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:39:42 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
- GNOME Shell 3.36.7

For Ubuntu 20.04, the most common cause of syslog floods is bug 1880405 so we should probably wait for that fix to be released in gnome-shell 3.36.9.

While waiting, everyone please check your Extensions app and ensure there are only the three built-in extensions listed. We need to exclude extensions as a first step because they cause so many bugs.

Hi everyone!

Bug seems to be still there with gnome-shell version 3.36.9
we have ubuntu 20.04 with gdm3, after login, desktop was freezing and syslog filled up to 25G

Sep 20 10:04:37 pc18 gnome-shell[487166]: == Stack trace for context 0x5602852a68b0 ==
Sep 20 10:04:37 pc18 gnome-shell[487166]: message repeated 10 times: [ == Stack trace for context 0x5602852a68b0 ==]
Sep 20 10:04:37 pc18 gnome-shell[487166]: The offending callback was AsyncReadyCallback().

Sep 20 10:04:37 pc18 gnome-shell[487166]: message repeated 32 times: [ == Stack trace for context 0x5602852a68b0 ==]
Sep 20 10:04:37 pc18 gnome-shell[487166]: 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.
Sep 20 10:04:37 pc18 gnome-shell[487166]: The offending callback was SourceFunc().

bug seems to be still open on gnome side:
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1868

I just got this on fully patched Ubuntu 21.10 (Kernel: 5.13.0-20-generic x86_64, Gnome Shell package: 40.5-1ubuntu2, Gnome version 40.4.0, Windowing System: Wayland, AMD A6 5400k processor with built-in Radeon graphics)

I was watching a movie on VLC and noticed that performance was a bit slow so I clicked the X to close the window. The window didn't disappear- It froze. SSHing in, I found systemd-journald was taking up all the CPU and an 11 GB /var/log/messages spamming with that same message.

I ended up just rebooting the machine.

Mike,

Can you attach (part of) your syslog showing the bug?

Here is mine:

Ubuntu: 21.10
Gnome version: 40.4.0
Window System: X11
Nvidia Driver: 495.44

syslog sample:
Nov 24 10:41:04 niqo-Alienware-Aurora-R11 gnome-shell[2570]: 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 24 10:41:04 niqo-Alienware-Aurora-R11 gnome-shell[2570]: The offending callback was SourceFunc().
Nov 24 10:41:04 niqo-Alienware-Aurora-R11 gnome-shell[2570]: 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 24 10:41:04 niqo-Alienware-Aurora-R11 gnome-shell[2570]: The offending callback was SourceFunc().
Nov 24 10:41:04 niqo-Alienware-Aurora-R11 gnome-shell[2570]: 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 24 10:41:04 niqo-Alienware-Aurora-R11 gnome-shell[2570]: The offending callback was SourceFunc().
Nov 24 10:41:04 niqo-Alienware-Aurora-R11 gnome-shell[2570]: 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 24 10:41:04 niqo-Alienware-Aurora-R11 gnome-shell[2570]: The offending callback was SourceFunc().

For info.

The bug also means that the systemd journal is growing at an extremely fast rate. Double whammy. All these files by default reside in the root file system. Which is usually created quite small.

With gnome-shell 3.36.9-0ubuntu0.20.04.2 I too see this with only the built-in "Desktop Icons", "Ubuntu AppIndicators", "Ubuntu Dock" extensions and no further extensions in ~/.local/share/gnome-shell/

$ journalctl -S -1hour | grep 'Jan 07 08:19:35' | sort | uniq -c
Hint: You are currently not seeing messages from other users and the system.
      Users in groups 'adm', 'systemd-journal' can see all messages.
      Pass -q to turn off this notice.
     22 Jan 07 08:19:35 LAP125300 gnome-shell[3286]: 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.
   4314 Jan 07 08:19:35 LAP125300 gnome-shell[3286]: 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.
     22 Jan 07 08:19:35 LAP125300 gnome-shell[3286]: The offending callback was paint(), a vfunc.
   4291 Jan 07 08:19:35 LAP125300 gnome-shell[3286]: The offending callback was SourceFunc().
     22 Jan 07 08:19:35 LAP125300 gnome-shell[3286]: The offending signal was paint on Gjs_ubuntu-dock_ubuntu_com_docking_DashToDock 0x5581d33fc7d0.

Just had my disk fill up today from this one

--

Computer science only has 2 hard problems:

  * Cache invalidation
  * Naming things
  * Off-by-one errors

I get this when moving my Lenovo T450 between docking stations, one of them with an external display connected. In general an external monitor connected to a docking station seems to be the source of much pain for 22.04LTS (wayland). The other docking station also used to have a small external display connected to it that I used to extend the desktop. I had to disconnect it, b/c the system was rather unstable and sluggish with occasional bursts of log spam that required reboot.

This happens to me too. Most common reason cause seems to be switching to another window in Chrome that happens to be a youtube video.

Maybe fixed in gjs 1.76.1 (Ubuntu 23.10 and later):
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1868