https://bugs.kde.org/show_bug.cgi?id=422111

--- Comment #72 from Sam Edwards <cfswo...@gmail.com> ---
I tried QDBUS_DEBUG=1; the extra output to the terminal slowed things down
enough that the race stopped happening. I had to redirect stderr to a
tmpfs-backed file to get the issue to happen again, but apparently redirecting
stderr shuts off the other debug logs?

I had no luck with getting DBus running over TCP either. The session launched,
but *slowly* -- it felt like the session launch kept blocking on something that
had to time out before it could continue. Once again, no race condition. I
didn't find it worthwhile to dig deeper.

The dbus-monitor --pcap worked, though. The messages are all in the expected
order - the org.kde.Solid.PowerManagement registration signal arrives after the
ListNames reply, despite the respective callbacks firing out of order. The
timestamps indicate that the signal is ~32.4 ms after the ListNames request
finishes, which is... quite the window, if those timestamps are accurate.

I'm not really sure how useful the dbus-monitor results are when DBus itself is
a suspect, but I'm thinking we should be pointing the finger at Qt regardless.
The single-threaded nature of dbus-daemon means they'd have to be *trying* to
introduce message races, and with all of these threads in plasmashell, all it
would take for a race there is for the two signals to take paths involving
different threads. Perhaps most importantly, most of the earliest reports here
are with Qt 5.15.0, which suggests this is a regression that appeared shortly
after upgrading to the 5.15 series.

I don't understand what you mean about plasma-nm making a blocking call
affecting plasmashell - isn't plasma-nm a different process? Wouldn't
plasmashell be unaware of other calls into DBus and especially of whether those
calls are performed in a blocking/nonblocking manner? Or are you talking about
interactions between plasma-nm and plasmashell *via* DBus?

Happy to debug the queue replay code if you point me to the file that contains
it! :)

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to