Logs spammed with thousands of lines of errors from ding
I have noticed in the journals, at least twice, on logging back in to a gdm session, the logs spammed with thousands of lines of errors from ding.
The exact errors are:-
(gjs:406963): Gjs-CRITICAL **: 08:17:31.499: 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 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.
gjs:406963): Gjs-CRITICAL **: 08:17:39.728: The offending callback was SourceFunc(). == Stack trace for context 0x562d0df161a0 == #0 562d0dfc6970 i /home/USERNAMEHIDDEN/.local/share/gnome-shell/extensions/ding@rastersoft.com/ding.js:92 (2d88fb78d178 @ 1383)
............ the above two lines are repeated thousands of times within a second before the next journal entry.
(gjs:406963): Gjs-CRITICAL **: 08:18:01.550: Attempting to run a JS callback during garbage collection. This is most likely caused by>
(gjs:406963): Gjs-CRITICAL **: 08:18:01.550: The offending callback was SourceFunc().
== Stack trace for context 0x562d0df161a0 ==
#0 562d0dfc6970 i /home/USERNAMEHIDDEN/.local/share/gnome-shell/extensions/ding@rastersoft.com/ding.js:92 (2d88fb78d178 @ 1383)
Unclear what exactly causes it, seems to be happen when I log back in after the session is locked.
Ding continues to work properly after logging back in without a problem. Session behaves normally.
I am attaching file of the exact logs preceeding the errors and after the error. There does appear to be an attempt to connect to nautilus immediately prior to the error that fails and succeeds immediately after the error. Is it related to that?
What is also interesting is that the initial GJS timestamp for the error is way behind the journal timestamp, if that indeed is a timestamp, at least looks like oneerrorlogs. The last timestamp on the GJS error has almost caught up to the journal timestamp.
I cannot seem to reliably reproduce the error. Will see if it happens again.
Journal logs are attached immediately preceding and after the error