-
Allison Karlitskaya authored
In the event that a GSettings object is being destroyed just as a change signal is being delivered, the destroying thread will race with the dconf worker thread for acquiring the lock on the GSettingsBackend. If the signalling thread gets there first then the destroying thread will block on the lock. The signalling thread adds a reference to the GSettings object that is being destroyed and releases the lock. The idea is that this should prevent the GSettings object from being destroyed and thus maintain its entry in the list. Unfortunately, the weak reference notify function is already running and as soon as we release the lock, the list entry is removed. The signalling thread crashes. This bug is indicative of a serious problem encountered in many situations where GObject instances are touched from multiple threads. Ideally, we will move to a place where g_object_ref() is not called at all on the GSettings object from the dconf worker thread and instead,...
3f119b2f