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().

Bug #1908429 reported by Lillo Gullo
216
This bug affects 39 people
Affects Status Importance Assigned to Milestone
GNOME Shell
Fix Released
Unknown
gjs (Ubuntu)
Incomplete
Undecided
Unassigned
gnome-shell (Ubuntu)
Incomplete
High
Unassigned

Bug Description

Issue is explained in detail here: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1868

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: gnome-shell 3.36.4-1ubuntu1~20.04.2
ProcVersionSignature: Ubuntu 5.4.0-53.59-generic 5.4.65
Uname: Linux 5.4.0-53-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.12
Architecture: amd64
CasperMD5CheckResult: skip
Date: Wed Dec 16 18:56:56 2020
DisplayManager: gdm3
InstallationDate: Installed on 2020-04-01 (258 days ago)
InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
RelatedPackageVersions: mutter-common 3.36.6-1ubuntu0.20.04.2
SourcePackage: gnome-shell
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Lillo Gullo (lillogullo) wrote :
Revision history for this message
Lillo Gullo (lillogullo) wrote :

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

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Please run this command:

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

and then attach the resulting text file here.

Changed in gnome-shell (Ubuntu):
importance: Undecided → High
tags: added: performance
Changed in gnome-shell (Ubuntu):
status: New → Incomplete
Revision history for this message
Lillo Gullo (lillogullo) wrote :

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

summary: - gnome-shell bug journald and syslog all filled up
+ 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().
Changed in gnome-shell (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Martin Althoff (hazymountain) wrote :

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

Revision history for this message
Martin Althoff (hazymountain) wrote :

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)

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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

Revision history for this message
Sander Jonkers (jonkers) wrote :

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.

Revision history for this message
Francois Thirioux (fthx) wrote :
Revision history for this message
Damien Lecan (dlecan) wrote :

Disk full today! Same error messages

syslog.* files about 30-40GB

Revision history for this message
Thiago (thiago-sayao) wrote :

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

Revision history for this message
Vaderf (vaderf) wrote (last edit ):

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

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

Revision history for this message
ubi admin (ubiadmin0) wrote :

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

Revision history for this message
Mike (web-g) wrote :

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.

Revision history for this message
Daniel van Vugt (vanvugt) wrote (last edit ):

Mike,

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

Revision history for this message
niqo (niqo01) wrote :

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().

Revision history for this message
Roger James (rogerjames99) wrote :

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.

Revision history for this message
Mark Carroll (mtbc) wrote :

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.

Revision history for this message
cha0s (the-real-cha0s) wrote : [Bug 1908429] Re: 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 conn

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

Changed in gnome-shell:
status: Unknown → New
Revision history for this message
Valery Ushakov (v-ushakov) wrote :

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.

Revision history for this message
Corey Huinker (corey-huinker) wrote :

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.

Changed in gnome-shell:
status: New → Fix Released
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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

Changed in gnome-shell (Ubuntu):
status: Confirmed → Incomplete
Changed in gjs (Ubuntu):
status: New → Incomplete
Revision history for this message
MM (bmn.one) wrote :

Happens in Ubuntu 22.04 kernel 6.5.0-14
floods syslog
rsyslogd 100% cpu
system unusable
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()

Revision history for this message
Ibrahim Ahmed (ibieebz) wrote :

OS: Ubuntu 20.04.6 LTS (GNU/Linux 5.4.0-169-generic x86_64)
Package: gnome-shell 3.36.9
I am getting similar issue, but on a different callback as per below:

gnome-shell[1742]: 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.

gnome-shell[1742]: The offending signal was user-changed on ActUserManager 0x5611315f9eb0.

Revision history for this message
kenorb (kenorb) wrote :

If you've got similar issue where ubuntu-dock disappeared, try running:

killall -HUP gnome-shell

to reload GNOME Shell.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.