https://bugs.kde.org/show_bug.cgi?id=354250
Oliver Henshaw <oliver.hens...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |oliver.hens...@gmail.com
--- Comment #18 from Oliver Henshaw <oliver.hens...@gmail.com> ---
Created attachment 99751
--> https://bugs.kde.org/attachment.cgi?id=99751&action=edit
stacktrace showing that main thread of other user's kded5 is blocked in
xcb/xlib
Can you identify the kded5 process PID belonging to the user you're about to
switch to with
$ ps aux | grep kded5
Then do
$ pstack PID
(as root or in logged in as the other user via your terminal) and paste the
results here?
On Fedora 22 I get the attached result. It looks like powerdevil gets stuck in
xcb while waiting for a reply from an Xlib call (one that should return
straight away). And I see QXcbConnection::processXcbEvents further up the
stack. Maybe there's a problem with nesting the xlib-on-xcb eventloop inside an
xcb event?
Whatever's happening, it seems to get unstuck when you actually switch to the
other user and all the kidletime events come flooding in. I also see floods of
other events in kded, e.g. the software update applet spams me with a load of
identical messages telling me how many packages are due for update.
If this is indeed the problem, completing the port of kidletime to xcb looks
like part of the long-term solution. I think there were problems when that was
tried before but hopefully everything that is called from the xcb event can be
ported.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
