GNOME Bugzilla – Bug 683519
Deadlock in g_dbus_connection_get_type()
Last modified: 2012-09-07 11:43:58 UTC
Created attachment 223675 [details] test program The attached test programs hangs frequently in e_source_registry_new_sync(). Perhaps one out of ten attempts work. I compiled it with "gcc -g /tmp/source.c -o /tmp/source `pkg-config --cflags --libs glib-2.0 libedataserver-1.2`" and ran it in a jhbuild shell, with a D-Bus session created manually in that environment. Running it with G_DBUS_DEBUG=message shows that no D-Bus traffic happens when it hangs. This affects SyncEvolution. I only noticed the problem after building GNOME 3.5 with jhbuild (Debian Testing as base system). On Debian Testing with just evolution-data-server compiled from source it worked fine.
+ Trace 230813
Thread 3 (Thread 0x7f35e4f4c700 (LWP 22385))
This looks beyond our reach, it appears to be deadlocked inside g_dbus_connection_get_type(). Forwarding this on to GIO maintainers.
(In reply to comment #1) > This looks beyond our reach, it appears to be deadlocked inside > g_dbus_connection_get_type(). > > Forwarding this on to GIO maintainers. You are very likely creating an object *instance* inside _class_init(). Don't do that. See https://bugzilla.gnome.org/show_bug.cgi?id=674885
Not as far as I can tell. What _is_ happening is g_dbus_object_manager_client_class_init() is registering a "connection" property of type G_TYPE_DBUS_CONNECTION at the same time dconf is trying to connect to its daemon over D-Bus.
(In reply to comment #3) > Not as far as I can tell. > > What _is_ happening is g_dbus_object_manager_client_class_init() is registering > a "connection" property of type G_TYPE_DBUS_CONNECTION at the same time dconf > is trying to connect to its daemon over D-Bus. That's probably why then. What a mess - until we fix GType, I guess you can work around it for now by calling g_type_ensure(G_TYPE_DBUS_CONNECTION) somewhere...
*** This bug has been marked as a duplicate of bug 674885 ***
(In reply to comment #4) > (In reply to comment #3) > > Not as far as I can tell. > > > > What _is_ happening is g_dbus_object_manager_client_class_init() is registering > > a "connection" property of type G_TYPE_DBUS_CONNECTION at the same time dconf > > is trying to connect to its daemon over D-Bus. > > That's probably why then. What a mess - until we fix GType, I guess you can > work around it for now by calling g_type_ensure(G_TYPE_DBUS_CONNECTION) > somewhere... That workaround, well, works. The question for e_source_registry_new_sync() now becomes "who works around the problem - the app or libedataserver?". I vote for libedataserver, because then the workaround only needs to be implemented once. I guess it could be put into e_source_registry_new_sync(). If other functions have similar issues, they probably will only be called after e_source_registry_new_sync(). Here's the patch that worked for me: diff --git a/libedataserver/e-source-registry.c b/libedataserver/e-source-registry.c index c9783d6..5685ecd 100644 --- a/libedataserver/e-source-registry.c +++ b/libedataserver/e-source-registry.c @@ -1281,6 +1281,8 @@ ESourceRegistry * e_source_registry_new_sync (GCancellable *cancellable, GError **error) { + g_type_ensure(G_TYPE_DBUS_CONNECTION); + return g_initable_new ( E_TYPE_SOURCE_REGISTRY, cancellable, error, NULL); Matthew, I can commit that if you want. FWIW, an app using the asynchronous e_source_registry_new() + g_main_context_iteration() (or running the loop) doesn't seem to be affect. I tried that in SyncEvolution and it worked.
(In reply to comment #6) > > + g_type_ensure(G_TYPE_DBUS_CONNECTION); Add a comment above that links to the bug?
Can't use g_type_ensure() yet since we only require GLib 2.32, but I added something equivalent, along with a comment linking to the bug. http://git.gnome.org/browse/evolution-data-server/commit/?id=6c4c1c6a1f40a6873be954a0b9d770e31726bd50