system unresponse for several seconds a couple of times per hour [Attempting to call back into JSAPI during the sweeping phase of GC... The offending signal was g-signal on GDBusProxy]

Bug #1825197 reported by Steyn Westbeek
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnome-shell (Ubuntu)
Won't Fix
High
Unassigned

Bug Description

My system is up-to-date on:

$ lsb_release -rd
Description: Ubuntu 18.10
Release: 18.10

$ apt-cache policy gnome-shell
gnome-shell:
  Installed: 3.30.2-0ubuntu1.18.10.1
  Candidate: 3.30.2-0ubuntu1.18.10.1

To provide you with an idea of the motivation for the origin in gnome-shell; I've included the lines in syslog that are displayed for many more occasions than presented below.

At the times that these messages are displayed in my logs I can still move my mouse, but mouse clicks are unresponsive and typing is frozen (but text does appear after freeze).

Apr 17 09:30:25 TUE001295 gnome-shell[11238]: 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.
Apr 17 09:30:25 TUE001295 org.gnome.Shell.desktop[11238]: == Stack trace for context 0x55f9f7a3f220 ==
Apr 17 09:30:25 TUE001295 gnome-shell[11238]: The offending signal was g-signal on GDBusProxy 0x55f9f7e68eb0.
Apr 17 09:30:25 TUE001295 gnome-shell[11238]: 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.
Apr 17 09:30:25 TUE001295 org.gnome.Shell.desktop[11238]: == Stack trace for context 0x55f9f7a3f220 ==
Apr 17 09:30:25 TUE001295 gnome-shell[11238]: The offending signal was g-signal on GDBusProxy 0x55f9f7e68eb0.
Apr 17 09:30:25 TUE001295 gnome-shell[11238]: 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.
Apr 17 09:30:25 TUE001295 org.gnome.Shell.desktop[11238]: == Stack trace for context 0x55f9f7a3f220 ==
Apr 17 09:30:25 TUE001295 gnome-shell[11238]: The offending signal was g-signal on GDBusProxy 0x55f9f7e68eb0.
Apr 17 09:30:25 TUE001295 gnome-shell[11238]: 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.
Apr 17 09:30:25 TUE001295 org.gnome.Shell.desktop[11238]: == Stack trace for context 0x55f9f7a3f220 ==
Apr 17 09:30:25 TUE001295 gnome-shell[11238]: The offending signal was g-signal on GDBusProxy 0x55f9f7e68eb0.
Apr 17 09:30:25 TUE001295 gnome-shell[11238]: 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.
Apr 17 09:30:25 TUE001295 org.gnome.Shell.desktop[11238]: == Stack trace for context 0x55f9f7a3f220 ==
Apr 17 09:30:25 TUE001295 gnome-shell[11238]: The offending signal was g-signal on GDBusProxy 0x55f9f7e68eb0.
Apr 17 09:30:25 TUE001295 gnome-shell[11238]: 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.
Apr 17 09:30:25 TUE001295 org.gnome.Shell.desktop[11238]: == Stack trace for context 0x55f9f7a3f220 ==
Apr 17 09:30:25 TUE001295 gnome-shell[11238]: The offending signal was g-signal on GDBusProxy 0x55f9f7e68eb0.
Apr 17 09:30:25 TUE001295 gnome-shell[11238]: 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.
Apr 17 09:30:25 TUE001295 org.gnome.Shell.desktop[11238]: == Stack trace for context 0x55f9f7a3f220 ==
Apr 17 09:30:25 TUE001295 gnome-shell[11238]: The offending signal was g-signal on GDBusProxy 0x55f9f7e68eb0.
Apr 17 09:30:25 TUE001295 gnome-shell[11238]: 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.
Apr 17 09:30:25 TUE001295 org.gnome.Shell.desktop[11238]: == Stack trace for context 0x55f9f7a3f220 ==
Apr 17 09:30:25 TUE001295 gnome-shell[11238]: The offending signal was g-signal on GDBusProxy 0x55f9f7e68eb0.
Apr 17 09:30:25 TUE001295 gnome-shell[11238]: 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.
Apr 17 09:30:25 TUE001295 org.gnome.Shell.desktop[11238]: == Stack trace for context 0x55f9f7a3f220 ==
Apr 17 09:30:25 TUE001295 gnome-shell[11238]: The offending signal was g-signal on GDBusProxy 0x55f9f7e68eb0.
Apr 17 09:30:25 TUE001295 gnome-shell[11238]: 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.
Apr 17 09:30:25 TUE001295 org.gnome.Shell.desktop[11238]: == Stack trace for context 0x55f9f7a3f220 ==
---
ProblemType: Bug
ApportVersion: 2.20.10-0ubuntu13.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
DisplayManager: gdm3
DistroRelease: Ubuntu 18.10
InstallationDate: Installed on 2019-03-07 (41 days ago)
InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3)
Package: gnome-shell 3.30.2-0ubuntu1.18.10.1
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 4.18.0-17.18-generic 4.18.20
Tags: cosmic third-party-packages
Uname: Linux 4.18.0-17-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True

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

Thanks for the bug report. I have encountered the same problems myself this week when stress testing parts of gnome-shell. But those parts and the cause might be different to yours. So please run:

  apport-collect 1825197

to send us more information about the system.

tags: added: cosmic
Changed in gnome-shell (Ubuntu):
importance: Undecided → High
status: New → Incomplete
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

As far as I can tell, the common error (from gjs):

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.

is caused by a type of mistake that has been made in JavaScript locations. And that mistake is common, in multiple locations in gnome-shell and its extensions. Although I don't yet understand what that mistake looks like in code :(

summary: system unresponse for several seconds a couple of times per hour
+ [Attempting to call back into JSAPI during the sweeping phase of GC...]
Revision history for this message
Steyn Westbeek (swestbeek) wrote : Dependencies.txt

apport information

tags: added: apport-collected third-party-packages
description: updated
Revision history for this message
Steyn Westbeek (swestbeek) wrote : GsettingsChanges.txt

apport information

Revision history for this message
Steyn Westbeek (swestbeek) wrote : ProcCpuinfoMinimal.txt

apport information

Revision history for this message
Steyn Westbeek (swestbeek) wrote : ProcEnviron.txt

apport information

Revision history for this message
Steyn Westbeek (swestbeek) wrote : Re: system unresponse for several seconds a couple of times per hour [Attempting to call back into JSAPI during the sweeping phase of GC...]

Thanks for the feedback!
I just send in the report collected by apport-collect, hope it helps.

Changed in gnome-shell (Ubuntu):
status: Incomplete → New
summary: system unresponse for several seconds a couple of times per hour
- [Attempting to call back into JSAPI during the sweeping phase of GC...]
+ [Attempting to call back into JSAPI during the sweeping phase of GC...
+ The offending signal was g-signal on GDBusProxy]
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Thank you for reporting this bug to Ubuntu.
Ubuntu 18.10 (cosmic) reached end-of-life on July 18, 2019.

See this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We appreciate that this bug may be old and you might not be interested in discussing it any more. But if you are then please upgrade to the latest Ubuntu version and re-test. If you then find the bug is still present in the newer Ubuntu version, please add a comment here telling us which new version it is in and change the bug status to Confirmed.

Changed in gnome-shell (Ubuntu):
status: New → Won't Fix
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.