On 16/06/15 11:28, Ignacio Casal Quinteiro wrote: > you should not be using the same object from different threads, > instead > you should probably idle to the main thread and to the signal from > there.
In the specific case of GDBus it is actually OK to use the same GDBusConnection from different threads (GDBus is designed for that), but... > In short terms, the application is doing the following: > > Thread 1: g_object_unref(connection); > Thread 2: g_dbus_connection_emit_signal(connection); ... if thread 2 does not have a guarantee that the connection will not reach its last-unref, then it is invalid for it to do *anything* that dereferences the connection. As a general rule, you should never do anything with a pointer if you cannot know that the object it points to is not going to be freed by another thread. For reference-counted objects, holding a reference yourself is enough to know that it will not be freed, unless there is a refcounting bug elsewhere. If thread 2 is already holding its own reference to the connection, check that you don't have too many unrefs somewhere else. > In case more details are requried, please let me know. I can > easily > reproduce the > issue at my place and already implemented a small test executable. If those hints are not enough to diagnose a bug in your own code, then yes we would need to see a failing test-case (as minimal as possible). In particular, if you think after further analysis that there is a bug in GDBus, we will need to see a test-case that demonstrates the bug. -- Simon McVittie Collabora Ltd. <http://www.collabora.com/> _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
