GNOME Bugzilla – Bug 685734
GTestDBus: problem with dconf and gvfs
Last modified: 2012-10-08 17:09:18 UTC
I'm porting tp-glib to use GTestDBus. The problem is that something implicitly loads gvfs and dconf and they keep a ref to the session GDBusConnection singleton. This causes g_test_dbus_down() to timeout waiting for the singleton to be destroyed. To work around this, I need to do this: export GIO_USE_VFS=local export GSETTINGS_BACKEND=memory I'm not sure what's the best fix tbh. Maybe we should have a way to make gvfs/dconf drop their ref to the singleton? Or maybe those 2 env var should be set in g_test_dbus_up()? Or maybe just document that users needs to take care of it?
I agree the right approach here is something like 1. Document that some library / external code may hold on to a GDBusConnection forever; and 2. Specifically mention GSettings and GVfs and those environment variables; and 3. mention that you generally always want to set those env vars in a test (if you use GVfs or GSettings, that is), otherwise you may pollute and/or get-polluted-from the user's environment
I feel as though there ought to be an easier way to do this - it's not at all obvious that those two environment variables will remain sufficient after upgrading GLib. One way to make this easier would be a general G_AVOID_MODULES (or something) with the semantics "try to load the built-in version of everything". (I'm not sure where that should draw the line, though.) Another would be to have some sort of explicit teardown stage that tries to free globally-allocated memory, as Matthias mentioned on <http://blogs.gnome.org/mclasen/2012/10/08/gnome-summit-sunday/>. I wonder whether g_dbus_connection_close_sync() is enough to make GVfs and DConf let go of it? (In reply to comment #1) > 3. mention that you generally always want to set those env vars in a test (if > you use GVfs or GSettings, that is) We don't use either GVfs or GSettings in our tests or in the library under test (telepathy-glib), but GIO helpfully loads them for us (the former when we instantiate a GFile, the latter I'm not sure).
(In reply to comment #2) > I feel as though there ought to be an easier way to do this - it's not at all > obvious that those two environment variables will remain sufficient after > upgrading GLib. > > One way to make this easier would be a general G_AVOID_MODULES (or something) > with the semantics "try to load the built-in version of everything". (I'm not > sure where that should draw the line, though.) Yeah, this is also related to setuid and the new "Writing GIO applications" http://developer.gnome.org/gio/unstable/ch02.html we put in the GIO docs for 2.34.0 (e.g. in security-sensitive applications, you want to avoid loading non-GIO code). Drawing the line is hard, sure... > Another would be to have some sort of explicit teardown stage that tries to > free globally-allocated memory, as Matthias mentioned on > <http://blogs.gnome.org/mclasen/2012/10/08/gnome-summit-sunday/>. I wonder > whether g_dbus_connection_close_sync() is enough to make GVfs and DConf let go > of it? I'd rather avoid loading them in the first place... as a counter-point, Ryan wants to nuke dynamically-loaded types so we're also moving in a direction where there's less cleanup going on (kinda weird to want both!). > We don't use either GVfs or GSettings in our tests or in the library under test > (telepathy-glib), but GIO helpfully loads them for us (the former when we > instantiate a GFile, the latter I'm not sure). Yeah, it can be surprising...
See also https://bugzilla.gnome.org/show_bug.cgi?id=678808
Actually this is really a duplicate. *** This bug has been marked as a duplicate of bug 678808 ***