summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAllison Ryan Lortie <desrt@desrt.ca>2016-04-26 10:39:42 +0200
committerAllison Ryan Lortie <desrt@desrt.ca>2016-04-26 15:20:16 +0200
commit62f320e6bb09b4e6454e6a49dc3a844b13b9cc34 (patch)
treed63d8a1ac9581a76ce9fdf3d3519ccccd0660365
parente118856430a798bbc529691ad235fd0b0684439d (diff)
downloadglib-62f320e6bb09b4e6454e6a49dc3a844b13b9cc34.tar.gz
GContextSpecificGroup: detach sources
GContextSpecificGroup has been somewhat broken for a rather long time: when we remove the last reference on an object held in the group, we try to clean up the source, but fail to actually remove it from the mainloop. We will soon stop emitting signals on the source (due to it having been removed from the hash table) but any "in flight" signals will still be delivered on the source, which continues to exist. This is a problem if the event is being delivered just as the object is being destroyed. This also means that we leave the source attached to the mainloop forever (and next time will create a new one)... This is demonstrated with the GtkAppChooser dialog which writes an update to the mimeapps.list file just as it is closing, triggering the app info monitor to fire just as it is being destroyed. Karl Tomlinson correctly analysed the problem and proposed this fix. https://bugzilla.gnome.org/show_bug.cgi?id=762994
-rw-r--r--gio/gcontextspecificgroup.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/gio/gcontextspecificgroup.c b/gio/gcontextspecificgroup.c
index b0eb279ff..211d76540 100644
--- a/gio/gcontextspecificgroup.c
+++ b/gio/gcontextspecificgroup.c
@@ -234,6 +234,7 @@ g_context_specific_group_remove (GContextSpecificGroup *group,
g_assert (css->instance == instance);
+ g_source_destroy ((GSource *) css);
g_source_unref ((GSource *) css);
g_main_context_unref (context);
}