Alright, after some discussions with Ryan, I had a look into this again, and I have now fixed the problem in compiz. Some notes about this:
* DBUS_SESSION_BUS_ADDRESS in the program's env isn't mandatory, since dbus can scrape that information from the root window property if it has X11 support
* DBUS_SESSION_BUS_ADDRESS *won't* appear in the program env if it was launched from a VT or SSH or something
* Compiz issues an UngrabServer request right after doing XQueryTree, and then initializes plugin screens right afterwards (before initializing every window).
* UngrabServer isn't a synchronous operation, so there's a race for the X Server to process that in time
* On CcpScreen's ctor, it will initialize libcompizconfig which loads backends (gconf)
* GConf initializes and starts DBus to get a connection with the gconf server
* GDbus sees that DBUS_SESSION_BUS_ADDRESS isn't set and calls dbus-launch --autolaunch to try and get the bus address
* dbus-launch --autolaunch calls get_bus_address_platform_specific (X11 backend) which calls XOpenDisplay () and XGetWindowProperty () to try and get the session bus address from the window prop
* The UngrabServer request hasn't been processed yet, so XOpenDisplay instantly fails
* GDbus is using g_spawn_sync incorrectly and doesn't restore normal child handling, so when the child process dbus-launch fails to return an address (very rare case), it just blocks forever until glib times out the request. This is what causes the apparent hang, then crash 2 minutes later
All of the items above the last one have been fixed compiz-side so this is no longer an issue (though it does pose an interesting problem that trying to get the session bus address while a server grab is active will fail - that is probably a bad thing and should be resolved, maybe a temp socket file should be created in the user's homedir?). Anyways, I believe that while the last item is essentially a corner-case, it still prints an interesting debug message if the command failed to get the bus address and should be fixed.
Alright, after some discussions with Ryan, I had a look into this again, and I have now fixed the problem in compiz. Some notes about this:
* DBUS_SESSION_ BUS_ADDRESS in the program's env isn't mandatory, since dbus can scrape that information from the root window property if it has X11 support BUS_ADDRESS *won't* appear in the program env if it was launched from a VT or SSH or something BUS_ADDRESS isn't set and calls dbus-launch --autolaunch to try and get the bus address address_ platform_ specific (X11 backend) which calls XOpenDisplay () and XGetWindowProperty () to try and get the session bus address from the window prop
* DBUS_SESSION_
* Compiz issues an UngrabServer request right after doing XQueryTree, and then initializes plugin screens right afterwards (before initializing every window).
* UngrabServer isn't a synchronous operation, so there's a race for the X Server to process that in time
* On CcpScreen's ctor, it will initialize libcompizconfig which loads backends (gconf)
* GConf initializes and starts DBus to get a connection with the gconf server
* GDbus sees that DBUS_SESSION_
* dbus-launch --autolaunch calls get_bus_
* The UngrabServer request hasn't been processed yet, so XOpenDisplay instantly fails
* GDbus is using g_spawn_sync incorrectly and doesn't restore normal child handling, so when the child process dbus-launch fails to return an address (very rare case), it just blocks forever until glib times out the request. This is what causes the apparent hang, then crash 2 minutes later
All of the items above the last one have been fixed compiz-side so this is no longer an issue (though it does pose an interesting problem that trying to get the session bus address while a server grab is active will fail - that is probably a bad thing and should be resolved, maybe a temp socket file should be created in the user's homedir?). Anyways, I believe that while the last item is essentially a corner-case, it still prints an interesting debug message if the command failed to get the bus address and should be fixed.