https://bugs.kde.org/show_bug.cgi?id=422111
--- Comment #69 from Sam Edwards <cfswo...@gmail.com> --- My hunch looks like it was correct; the new log message I added fires off when the bug occurs: kde.systemtray: m_sessionServiceWatcher->serviceRegistered( "org.kde.Solid.PowerManagement" ) but m_dbusSessionServiceNamesFetched=false At this point, I'm pretty confident that the order of events is: 1) DBusServiceObserver is created and initialized, with m_dbusSessionServiceNamesFetched=false as per defaults. Plugins are registered, and the watcher has watch patterns added. 2) DBusServiceObserver::initDBusActivatables() is called; the async ListNames() request is sent to the session DBus 3) Session DBus server prepares a list of all services presently registered 4) powerdevil finishes initialization and registers the PowerManagement service (this happens after step 3 above, so it's not in the list) 5) ??? 6) m_sessionServiceWatcher's serviceRegistered signal fires to inform DBusServiceObserver of #4, above 7) The async ListNames() call returns the list from #3, above When the issue does NOT happen, steps 6<->7 are reversed The mystery is what's going on in #5, causing these callbacks to run in a different order. As I see it, there are two possible culprits: a) DBus itself: It might be that, while DBus does have strict ordering guarantees between a given pair of endpoints, no ordering guarantees exist with respect to a third endpoint. Hence, the race is between the org.freedesktop.DBus service's reply to ListNames() and powerdevil's (connection's) broadcast announcement of a newly-registered service. b) Qt: It's possible that, since one signal comes by way of a QDBusPendingCallWatcher, and the other by way of a QDBusServiceWatcher, there are races in how the signals themselves are handled. I find both of these cases pretty hard to believe, though. 'A' shouldn't be possible since dbus-daemon is single-threaded: if it is preoccupied handling/returning a ListNames() call, it can't even see the service registration request yet. But 'B' shouldn't be possible either if Qt is dispatching these signals in FIFO order and in the same thread that's reading the incoming messages off of the connection. (Maybe it doesn't?) I'm going to try to get my session DBus rebound to 127.0.0.1 and do a Wireshark capture on lo. It'd be very helpful to know the actual order that dbus-daemon is sending these things to plasmashell. -- You are receiving this mail because: You are watching all bug changes.
