GNOME Bugzilla – Bug 736775
wall-clock: disconnect GSettings signals when disposing
Last modified: 2017-04-07 22:32:43 UTC
See patch
Created attachment 286333 [details] [review] patch The GSettings object can outlive GnomeWallClock, so explicitly disconnect the changed signal when disposing the object.
Review of attachment 286333 [details] [review]: GSettings aren't singletons, how can we outlive the settings object?
Not really sure; the crash I'm observing here is in gnome-initial-setup. I think the code flow is the following: - a gnome-initial-setup page owns a GnomeWallClock object, which internally has a GSettings to org.gnome.deskop.interface - language changes in gnome-initial-setup; an idle timeout fires that will destroy and recreate all pages - page gets destroyed and immediately afterwards another one will be created; in the constructor, it will create another GSettings to org.gnome.desktop.interface, set a setting and immediately unref it - dconf will call back into the old GSettings instance, which will emit a change signal, but the old GnomeWallClock object is gone/in destruction already I am attaching a full backtrace.
Created attachment 286336 [details] backtrace
Sounds rather like the wall clock isn't being destroyed, no?
There's no gis-location-page.c anymore. There's no wall clock in gnome-initial-setup, never was. I'm guessing you forked that...
*** This bug has been marked as a duplicate of bug 780861 ***