GNOME Bugzilla – Bug 783795
[PATCH] gio: ignore signals before GetManagedObject() returns
Last modified: 2018-05-24 19:37:17 UTC
Created attachment 353766 [details] [review] Proposed patch The InterfaceAdded and InterfaceRemoved signals delivered after GDBusObjectManagerClient subscribes to them and before it gets the list of the managed objects confuse the object manager client: (process:1700): GLib-GIO-WARNING **: gdbusobjectmanagerclient.c:1585: Processing InterfaceRemoved signal for path ... but no object proxy exists They are useless too -- the GetManagedObject() call returns an up-to-date object list. Ignore them untils we got an object list.
I think this is not right. at least, process_get_all_result() must not access map_object_path_to_object_proxy without a lock. (there is already a bug in add_interfaces() which adds an object without lock). Also, this doesn't solve the race at all. D-Bus evens on the main thread are in sync (ordered). However, during async init, we call initable_iface_init() on another tread, calling there "GetManagedObjects" syncronously. The asynchronous events race against the synchronous call and process_get_all_result(). E.g. - thread2 calls GetManagedObjects synchronously. It find interface "A". - shortly after, server deletes interface "A" and thread1 receives the "InterfaceRemoved" signal and processes it (logging a bogus warning, that the object doesn't exist - even worse, thread1 now adds the interface that is already gone. Making synchronous requests on another thread cannot be reconciled with the events from D-Bus. It's racy, and the only fix is to process all D-Bus communication on the same thread.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1273.