GNOME Bugzilla – Bug 747506
Garbage collector complains during shutdown
Last modified: 2018-08-16 16:02:24 UTC
Steps to reproduce: 1) start application from console 2) toggle the search button 3) close the main window 4) wait for the inactivity-timeout of 12s to expire This shows up in the console: (gnome-documents:21023): Gjs-CRITICAL **: 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() or dispose() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked. (gnome-documents:21023): Gjs-CRITICAL **: 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() or dispose() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked. (gnome-documents:21023): Gjs-CRITICAL **: The offending signal was destroy on GtkBox 0x29e3510. (gnome-documents:21023): Gjs-CRITICAL **: 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() or dispose() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked. (gnome-documents:21023): Gjs-CRITICAL **: The offending signal was destroy on GtkSearchBar 0x2473590. (gnome-documents:21023): Gjs-CRITICAL **: 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() or dispose() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked. (gnome-documents:21023): Gjs-CRITICAL **: The offending signal was destroy on GdTaggedEntry 0x292cc10.
Created attachment 301155 [details] [review] embed: Silence the garbage collector I don't know what is going on here, but it looks similar to the issue in commit 53fe30610
Created attachment 301156 [details] [review] embed: Silence the garbage collector
I am still getting one of these with the same set of steps: (gnome-documents:22697): Gjs-CRITICAL **: 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() or dispose() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked. And I have this: $ G_DEBUG=fatal-criticals DOCUMENTS_RUN_DEBUG=1 /opt/bin/gnome-documents (gdb) run ... (gdb) bt
+ Trace 234947
I don't know if there are smarter ways to debug this, so any suggestions are welcome.
I finally read gjs/modules/signals.js and found a few places where our signal handler management is broken. It can explain this bug and also why we had to explicitly destroy the toolbars in commit 53fe30610
Created attachment 301276 [details] [review] view: Remove unused signal handler IDs
Created attachment 301277 [details] [review] view: Disconnect from global objects when the widget is destroyed
Created attachment 301278 [details] [review] mainToolbar: Disconnect from DocumentManager when destroyed
Created attachment 301279 [details] [review] mainToolbar: Clean up
Created attachment 301284 [details] [review] preview: Clean up
Created attachment 301285 [details] [review] preview: Disconnect from global objects when the widget is destroyed
Review of attachment 301276 [details] [review]: Looks good
Review of attachment 301277 [details] [review]: Looks good
Review of attachment 301278 [details] [review]: OK
Review of attachment 301279 [details] [review]: Sure
Review of attachment 301284 [details] [review]: Yep
Review of attachment 301285 [details] [review]: OK
Thanks for tracking these down, Debarshi!
These still don't address the CRITICALS from gjs. Needs further investigation.
Created attachment 308348 [details] [review] embed: explicitly destroy the titlebar since GtkApplicationWindow when closed doesn't destroy the titlebar, do it explicitly
Review of attachment 308348 [details] [review]: ::: src/embed.js @@ +165,3 @@ + function() { + this._titlebar.destroy(); + })); This is basically the same thing as attachment 301156 [details] [review] The problem is that it still leaves behind one of the CRITICALs, and it might be the root cause behind the titlebar not getting destroyed. However, I failed to track it down. I am torn between committing this (hack?) to silence the bulk of the CRITICALs and finding the root cause behind this. Cosimo?
Review of attachment 308348 [details] [review]: I wonder if commit b941dcc9199 is of any help here.
*** Bug 789429 has been marked as a duplicate of this bug. ***
Another duplicate: https://gitlab.gnome.org/GNOME/gnome-documents/issues/9
Created attachment 373337 [details] [review] preview, selections: Be nice to the garbage collector during shutdown
Comment on attachment 373337 [details] [review] preview, selections: Be nice to the garbage collector during shutdown I pushed this to master, so that we can have it in the 3.29.91 tarball. My discussions with Philip Chimento confirm that connecting to GtkWidget::destroy is fine, but vfunc_destroy is not, as evidenced by: https://gitlab.gnome.org/GNOME/gnome-shell/commit/98b50fd9423e57 However, neither of us have been able to explain exactly why that might be. In the meantime, while we figure that out, this patch seems to address a real user-visible problem. With current versions of GJS (>= 1.52), gnome-documents crashes instead of just logging CRITICALs on shutdown, and this change fixes that.