...so it could happen that both the main thread at > internal_bus_get > dbus_bus_get_private > avahi_dbus_bus_get > avahi_client_new > sd::AvahiNetworkService::setup > sd::DiscoveryService::DiscoveryService > sd::DiscoveryService::setup > SdDLL::RegisterRemotes [...] as well as the thread > internal_bus_get > dbus_bus_get > dbusConnectToNameOnBus > sd::BluetoothServer::run > threadFunc > osl_thread_start_Impl > start_thread spawned from the main thread at > sd::BluetoothServer::setup > sd::RemoteServer::setup > SdDLL::RegisterRemotes [...] are in D-Bus's internal_bus_get simultaneously (with disastrous consequences, like SEGV) despite the _DBUS_LOCK(bus) there, unless you previously called dbus_threads_init_default. (Which the D-Bus documentation makes you believe can be called from multiple threads, though a look at the implemenation makes it clear that it really should be called from the main thread before any other threads are created---which we still don't do; oh my.) Other places that (indirectly) use D-Bus (tubes/source/file-transfer-helper.c, vcl/generic/fontmanager/fontconfig.cxx, vcl/unx/gtk/window/gtksalframe.cxx might need this, too. Change-Id: I912829c615b46b05a89c07bd044b04f1e5f5e7ba