Systemd journal filled with errors re: JS callback during garbage collection in daemon.js:1128

[matthew02]

Describe the bug

Having GSConnect installed and enabled fills my Systemd journal. I have a 100MB size limit on the journal, otherwise I expect it would overtake my entire system. The full 100MB is less than one second's worth of logs. I generated a support log that filled with 70,000 messages (11MB) in just a few seconds. The journal and support log repeat the exact same four messages over and over.

Mar 21 13:13:08 gjs[1578]: 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.
Mar 21 13:13:08 gjs[1578]: The offending callback was SourceFunc().
Mar 21 13:13:09 dbus-daemon[1578]: == Stack trace for context 0x5615c75741a0 ==
Mar 21 13:13:09 dbus-daemon[1578]: #0   5615c7625870 i   /home/smith/.local/share/gnome-shell/extensions/gsconnect@andyholmes.github.io/service/daemon.js:1128 (20315ca8d178 @ 1324)

Additionally, my device appears to be paired with GSConnect, but GSConnect doesn't appear to be paired with the device. Both are nonfunctional.

Steps To Reproduce:

Run gsconnect and watch.

Expected behavior

Logs don't fill up and GSConnect pairs correctly.

Support Log

GSConnect Version: 34
GSConnect Install: user
GJS: 16400
XDG_SESSION_TYPE: x11
GDMSESSION: gnome-xorg
--------------------------------------------------------------------------------
Mar 21 13:13:08 gjs[1578]: 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.
Mar 21 13:13:08 gjs[1578]: The offending callback was SourceFunc().
Mar 21 13:13:09 dbus-daemon[1578]: == Stack trace for context 0x5615c75741a0 ==
Mar 21 13:13:09 dbus-daemon[1578]: #0   5615c7625870 i   /home/smith/.local/share/gnome-shell/extensions/gsconnect@andyholmes.github.io/service/daemon.js:1128 (20315ca8d178 @ 1324)
***The previous four lines are repeated tens of thousands of times in just a few seconds.***

System Details (please complete the following information):

• GSConnect version: [34.r4.ge21a0ef5-1]
  • Installed from: [Arch User Repository]
• GNOME/Shell version: [3.36.0]
• Distro/Release: [Arch]

GSConnect environment (if applicable):

• Paired Device(s): [Galaxy Note 9]
• KDE Connect app version: [1.13.7]

Additional Notes:

Appears to be very similar to Issue #588

[andyholmes]

Are you running KDE Connect on your machine (eg. kdeconnectd)?

[matthew02]

No, but I suspect GSConnect is listening?

$ lsof -i UDP:1716
COMMAND  PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
gjs     1578 smith   17u  IPv6  30675      0t0  UDP *:xmsg 

[andyholmes]

Have you recently re-installed the Android app or wiped GSConnect's settings? Also, have you tried unpairing the phone on either side and re-pairing?

[matthew02]

I haven't reinstalled or wiped settings. I updated GSConnect on 2020/03/13. The version jumped considerably with the update (21.r12.g6c8ab5d8-1·->·34.r4.ge21a0ef5-1). KDE Connect was last updated on 2020/01/13 (1.13.6 -> 1.13.7).

I unpaired on the phone and it now times out anytime I try to pair again. When I click the pair button in GSConnect, nothing happens.

They are on the same network and I can ping the phone from the desktop.

[andyholmes]

In that case you'll probably want to ensure you're unpaired in the phone, then follow the steps for resetting all data.

If you have installed this from your distribution's package manager, you'll probably want to:

1. Uninstall GSConnect
2. Follow the steps to reset
3. Install GSConnect

v21 is about a year old, so we don't usually keep settings migration code around that long. Probably some older settings are causing problems here.

EDIT

I have been looking through the Lan connection code trying to see where this might happen, just so I'm clear :) The problem with GSource callbacks like that is they end up in the global event loop, which is why the error seems to be coming from daemon.js even though it's almost definitely in lan.js somewhere.

These aren't impossible to track down, but they are a pain since it would require you running GSConnect through gdb, getting a backtrace, etc. Probably the easier fix is to reset your settings, but we can still do this if we need to.

[matthew02]

Well, it's working now. I wiped it and reinstalled it a few times with no luck. Then I ran it through gdb and it started working. I don't know what I did wrong the other times, but it's good now. No spam in my journal and everything is back to normal. Thanks for your help! Sorry I wasted your time with something so simple.

[andyholmes]

Okay, no problem. This will probably happen with other users updating from Ubuntu 18.04, too :/

[matthew02]

One last thing... I don't know if it's important or not, but when I run GSConnect from the cli, gjs throws this out...
(GSConnect:42863): GLib-CRITICAL **: 23:21:01.166: g_variant_new_string: assertion 'string != NULL' failed
It doesn't seem to affect anything that I can tell, but I wanted to let you know, just in case it is relevant.

[andyholmes]

Ah yeah, that happens deep in GApplication somewhere during DBus registration. Fortunately it doesn't seem to affect anything.

I don't have a minimal reproducer, but I suspect it's some binding issue in GJS, possibly related to #96.