Bug 489840 - kglobalacceld 100% CPU in Xvnc session
Summary: kglobalacceld 100% CPU in Xvnc session
Status: REPORTED
Alias: None
Product: frameworks-kglobalaccel
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 6.1.0
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-07-06 18:12 UTC by Robin Bankhead
Modified: 2024-12-11 12:26 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
TigerVNC Xvnc session log (203.81 KB, text/x-log)
2024-07-06 18:12 UTC, Robin Bankhead
Details
TigerVNC Xvnc session log with kglobalacceld debug output (116.02 KB, text/plain)
2024-08-12 11:20 UTC, Robin Bankhead
Details
TigerVNC Xvnc session log with timestamps (142.22 KB, text/x-log)
2024-08-12 21:45 UTC, Robin Bankhead
Details
perf.data capture, xz-compressed (raw size 414MB) (1.55 MB, application/x-xz)
2024-08-18 14:02 UTC, Robin Bankhead
Details
hotspot (no symbols) (160.90 KB, image/png)
2024-08-18 16:43 UTC, fanzhuyifan
Details
perf.data capture, xz-compressed (raw size 387MB) (1.03 MB, application/x-xz)
2024-08-18 20:52 UTC, Robin Bankhead
Details
perf.data.perfparser exported from hotspot, xz-compressed (431.78 KB, application/x-xz)
2024-08-19 00:46 UTC, Robin Bankhead
Details
Screenshot of Gammaray attached to kglobalacceld in Xvnc session (732.25 KB, image/png)
2024-08-19 19:46 UTC, Robin Bankhead
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robin Bankhead 2024-07-06 18:12:18 UTC
Created attachment 171431 [details]
TigerVNC Xvnc session log

SUMMARY
When a plasma-x11 session is launched in TigerVNC's Xvnc on current Gentoo (default OpenRC-based Plasma profile), kglobalacceld does not initialise correctly: the shortcuts it should manage do not work, and as soon as the session receives any keyboard input via the VNC client, it immediately goes to 100% CPU.

If manually killed and relaunched, the CPU surge is not repeated but keyboard input is completely disabled - not just the shortcuts, it's not even possible to e.g. type text in KWrite. After this there are also other input dysfunctions seen, possibly indicating spurious modifier-key down states: e.g. Scrolling down with the wheel of a mouse on any window reduces its opacity; dragging on a scrollbar moves the whole window.

A version of this bug existed on the same host under KDE5, with the difference that killing and relaunching the then-named kglobalaccel5 *did* allow it to function normally thereafter (and there was none of the brokenness described above).

STEPS TO REPRODUCE
1.  emerge net-misc/tigervnc kde-plasma/plasma-desktop:6
2. Configure and start tigervnc initscript for existing user of plasma-x11 desktop
3. Connect to Plasma VNC session from TigerVNC vncviewer on another machine
4. Press any key

OBSERVED RESULT
kglobalacceld process goes to 100% and global shortcuts are unavailable.

EXPECTED RESULT
Global shortcuts can be used as configured and CPU does not melt.

SOFTWARE/OS VERSIONS
Operating System: Gentoo Linux 
KDE Plasma Version: 6.1.2
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2
Kernel Version: 6.9.1-gentoo (64-bit)
Graphics Platform: X11
Processors: 4 × Intel® Core™ i7-7600U CPU @ 2.80GHz
Memory: 15.4 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 620
Manufacturer: LENOVO
Product Name: 20HMS17U03
System Version: ThinkPad X270

ADDITIONAL INFORMATION
I described the KDE5 occurrence of this bug in the existing and very old Bug #306352 , however I think myself and others were wrong to glom onto that older issue with a grab-bag of very differing symptoms, contexts and apparent triggers. I'm hopeful that this single very specific scenario can be examined in isolation to get purchase on what the cause might be.

Attached is a VNC session log in which I

- Started the tigervnc initscript from a console VT with plasmax11 session configured for my user
- connected via tigervnc-client from another machine
- Pressed CTRL key to trigger the CPU surge
- Issued "killall -USR1 kglobalacceld" via a desktop shortcut (only way I can do so when the bug triggers)
- Opened yakuake via its tray icon
- Opened Kwrite and dolphin from iconbar to test shortcut function
- Issued "/usr/libexec/kglobalacceld" in yakuake
- Attempted global shortcuts e.g. Alt-Tab with the opened apps (nope)
- Attempted typing in another tab in yakuake (nope)
- Killed kglobalacceld again by closing the tab in yakuake
- Shutdown the machine
Comment 1 Robin Bankhead 2024-07-13 10:37:41 UTC
I obtained a change in behaviour by removing all KDE/Plasma related content from ~/.cache folder.

Having done this and launched a new tigervnc Xvnc session, the CPU surge starts as soon as the VNC client connects - no manual keypress is required to trigger it. (The subsequent behaviour on killing/restarting kglobalacceld is the same.)
Comment 2 fanzhuyifan 2024-08-01 20:05:59 UTC
This seems to have the same root cause as BUG 306352, and should be fixed by https://invent.kde.org/plasma/kglobalacceld/-/commit/a35a39e5d9f76b0e4b958a4533046cb8247298b6, which will be included in the 6.2 release. So I am marking this as waitingforinfo now.

If the issue persists with the referenced commits, feel free to remark this as reported.
Comment 3 Robin Bankhead 2024-08-03 14:42:35 UTC
Thanks. We will see in October. I spotted this commit and did wonder if it might be pertinent.

However I note that your description of the issue describes the CPU surge as being "1 minute plus"; my finding is that it continues indefinitely (I have let it run up to about 15 minutes). Does this still fit within your diagnosis?

PS: a small (and probably predictable) further observation: Connecting to the session in "view only" mode, the bug does not trigger. If the session is then switched to full-input (done within the TigerVNC vncviewer settings mid-session), it triggers immediately (no keyboard input required).
Comment 4 Andreas Sturmlechner 2024-08-11 16:13:39 UTC
(In reply to Robin Bankhead from comment #3)
> Thanks. We will see in October. I spotted this commit and did wonder if it
> might be pertinent.
As a Gentoo user, you don't have to wait for this to arrive by release. Try and apply this via user patch: https://wiki.gentoo.org/wiki//etc/portage/patches
Comment 5 Robin Bankhead 2024-08-11 23:52:52 UTC
Rebuilt kglobalacceld-6.1.2 with the patch from comment #2 applied. No change in bug behaviour :(
Comment 6 fanzhuyifan 2024-08-12 00:06:10 UTC
When kglobalacceld uses 100% of CPU, could you attach a gdb instance to it, press Ctrl-C, and upload the results of `thread apply all backtrace full`? This is to see where kglobalacceld is stuck at. You would need to install debug symbols.

Could you reattach the logs if you add the following environment variable before running kglobalacceld? 
QT_LOGGING_RULES="kf.globalaccel.kglobalacceld.debug=true"

Thanks!
Comment 7 Robin Bankhead 2024-08-12 00:26:21 UTC
Will do - once I re-teach myself how. Been over a decade.

Ctrl+C might not work under the bugged condition within the VNC session - is there any problem with doing that in a VT, or in a parallel SSH session?

Also: In the other bug I note that the commit I just tried is just part of a merge request that includes other stuff, is this what I should be using to patch?

https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/52.diff
Comment 8 fanzhuyifan 2024-08-12 00:31:29 UTC
(In reply to Robin Bankhead from comment #7)
> Will do - once I re-teach myself how. Been over a decade.
> 
> Ctrl+C might not work under the bugged condition within the VNC session - is
> there any problem with doing that in a VT, or in a parallel SSH session?

Both are fine.

> Also: In the other bug I note that the commit I just tried is just part of a
> merge request that includes other stuff, is this what I should be using to
> patch?
> 
> https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/52.diff

The other commit shouldn't be needed, since it just removes redundant returns: https://invent.kde.org/plasma/kglobalacceld/-/commit/864dc2b1aa565fab21f957b4d80c499679efdf74
Comment 9 Robin Bankhead 2024-08-12 01:03:03 UTC
Have rebuilt kglobalacceld with the full MR patch -- no change, as you expected -- and without stripping. If I have to do the same for other packages as well, it will be a while before I can do this as it will precipitate a full upgrade. If not, I will get gdb built tomorrow night and test then.

On this run I issued

$ export QT_LOGGING_RULES="kf.globalaccel.kglobalacceld.debug=true"

before starting the tigervnc initscript, but this did not lead to any additional output showing up in the Xvnc log. Perhaps this was not the appropriate method of supplying the env var to the session?
Comment 10 fanzhuyifan 2024-08-12 01:05:23 UTC
(In reply to Robin Bankhead from comment #9)
> $ export QT_LOGGING_RULES="kf.globalaccel.kglobalacceld.debug=true"
This environment variable needs to be exposed to kglobalacceld before it is started. Unfortunately I am not familiar with openrc and I cannot help you here. In systemd systems, a common way is to put it in /etc/environment.
Comment 11 Robin Bankhead 2024-08-12 11:20:55 UTC
Created attachment 172536 [details]
TigerVNC Xvnc session log with kglobalacceld debug output

Attaching Xvnc log with the debug-level output enabled for kglobalacceld.

In the logged session I simply launched the session, connected a viewer (which triggered the bug), waited ~1min, then killed it and logged out.
Comment 12 fanzhuyifan 2024-08-12 15:52:38 UTC
(In reply to Robin Bankhead from comment #11)
> Created attachment 172536 [details]
> TigerVNC Xvnc session log with kglobalacceld debug output
> 
> Attaching Xvnc log with the debug-level output enabled for kglobalacceld.
> 
> In the logged session I simply launched the session, connected a viewer
> (which triggered the bug), waited ~1min, then killed it and logged out.

Thanks! Looking at the logs, nothing seems super wrong. I see one remapping due to XCB_XKB_NEW_KEYBOARD_NOTIFY, with doesn't seem like a lot.

Any chance you could get timestamps in front of the log lines, so that we know how long everything is taking? E.g., take a look at https://serverfault.com/questions/310098/how-to-add-a-timestamp-to-bash-script-log
Comment 13 fanzhuyifan 2024-08-12 16:11:22 UTC
Also, could you install debug symbols for kglobalacceld, run "perf record -p <pid of kglobalacceld> --call-graph dwarf", wait for ~10s, press Ctrl-C, and upload the resulting perf.data?
Comment 14 Robin Bankhead 2024-08-12 20:16:09 UTC
(In reply to fanzhuyifan from comment #6)
> When kglobalacceld uses 100% of CPU, could you attach a gdb instance to it,
> press Ctrl-C, and upload the results of `thread apply all backtrace full`?
> This is to see where kglobalacceld is stuck at. You would need to install
> debug symbols.
> 
> Could you reattach the logs if you add the following environment variable
> before running kglobalacceld? 
> QT_LOGGING_RULES="kf.globalaccel.kglobalacceld.debug=true"
> 
> Thanks!

Output below:
----------------------------------
robin@lentoo ~ $ gdb -p `pidof kglobalacceld`
GNU gdb (Gentoo 15.1 vanilla) 15.1
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 3000
[New LWP 3028]
[New LWP 3021]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007f9fc6668180 in ?? () from /usr/lib64/libglib-2.0.so.0
(gdb) Quit
(gdb) thread apply all backtrace full

Thread 3 (Thread 0x7f9fc20006c0 (LWP 3021) "QDBusConnection"):
#0  0x00007f9fc6d2266f in poll () at /lib64/libc.so.6
#1  0x00007f9fc666b8d7 in ??? () at /usr/lib64/libglib-2.0.so.0
#2  0x00007f9fc666bfa0 in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0
#3  0x00007f9fc72c1670 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt6Core.so.6
#4  0x00007f9fc750f2aa in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt6Core.so.6
#5  0x00007f9fc744c8c0 in QThread::exec() () at /usr/lib64/libQt6Core.so.6
#6  0x00007f9fc6a65b8e in ??? () at /usr/lib64/libQt6DBus.so.6
#7  0x00007f9fc73ee76a in ??? () at /usr/lib64/libQt6Core.so.6
#8  0x00007f9fc6cc3379 in ??? () at /lib64/libc.so.6
#9  0x00007f9fc6d2f2cc in ??? () at /lib64/libc.so.6

Thread 2 (Thread 0x7f9fc16006c0 (LWP 3028) "QXcbEventQueue"):
#0  0x00007f9fc6d2266f in poll () at /lib64/libc.so.6
#1  0x00007f9fc5b1c4a2 in ??? () at /usr/lib64/libxcb.so.1
#2  0x00007f9fc5b1e86a in xcb_wait_for_event () at /usr/lib64/libxcb.so.1
#3  0x00007f9fc2d7b418 in ??? () at /usr/lib64/qt6/plugins/platforms/../../../libQt6XcbQpa.so.6
#4  0x00007f9fc73ee76a in ??? () at /usr/lib64/libQt6Core.so.6
#5  0x00007f9fc6cc3379 in ??? () at /lib64/libc.so.6
#6  0x00007f9fc6d2f2cc in ??? () at /lib64/libc.so.6

Thread 1 (Thread 0x7f9fc2ddce40 (LWP 3000) "kglobalacceld"):
#0  0x00007f9fc6668180 in ??? () at /usr/lib64/libglib-2.0.so.0
#1  0x00007f9fc6669fed in ??? () at /usr/lib64/libglib-2.0.so.0
#2  0x00007f9fc666b4dc in ??? () at /usr/lib64/libglib-2.0.so.0
#3  0x00007f9fc666b816 in ??? () at /usr/lib64/libglib-2.0.so.0
#4  0x00007f9fc666bfa0 in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0
#5  0x00007f9fc72c1670 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt6Core.so.6
#6  0x00007f9fc750f2aa in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt6Core.so.6
#7  0x00007f9fc750f45a in QCoreApplication::exec() () at /usr/lib64/libQt6Core.so.6
#8  0x0000558d983bfa9c in main ()
-----------------------------

Guessing you will need me to obtain symbols for other libs shown above? (As mentioned I need to recompile packages to get them, yay Gentoo).
Comment 15 Robin Bankhead 2024-08-12 20:32:17 UTC
(In reply to fanzhuyifan from comment #12)
> Any chance you could get timestamps in front of the log lines, so that we
> know how long everything is taking? E.g., take a look at
> https://serverfault.com/questions/310098/how-to-add-a-timestamp-to-bash-
> script-log

Unfortunately how tigervnc's vncsession binary handles console output seems to be hardcoded. It goes in ~/.vnc/myhostname:1.log and it rotates-out the previous file on launch so I would have to manually tail it after launch. Guess that's adequate to capture when the bug is triggered.

Do you want millisecond resolution? Will doing tail -f on the file provide that with sufficient accuracy?
Comment 16 Robin Bankhead 2024-08-12 21:45:07 UTC
Created attachment 172567 [details]
TigerVNC Xvnc session log with timestamps

Output log with 1s-resolution timestamps; I connect viewer, trigger the bug by pressing left CTRL key at 22:29:01, do nothing for 1min, then kill kglobalacceld and log out.

Regarding "perf" that looks a sizeable package to build (141MB source tarball) so I may not have an opportunity to do so before the weekend.
Comment 17 Robin Bankhead 2024-08-18 14:02:02 UTC
Created attachment 172729 [details]
perf.data capture, xz-compressed (raw size 414MB)

perf data as requested, ~10s worth captured just after triggering the bug. This is now under kglobalacceld-6.1.4 (without the above patch applied).
Comment 18 fanzhuyifan 2024-08-18 16:43:29 UTC
Created attachment 172732 [details]
hotspot (no symbols)

Thanks!

So the log file doesn't seem to have anything suspicious -- the registering/unregistering after remapping all finish in < 1s.

For the perf result, it seems that the top two hotspots (62.1% and 26.3%) are symbols in libglib and libQt6Core. Would you be able to install debug symbols for these, and use https://github.com/KDAB/hotspot?tab=readme-ov-file#visualizing-data to see what these are? If you could also go to the caller/callee tab and let us know what is calling those that would be great.

I understand that getting debug symbols is rather complicated on gentoo, but unfortunately those are needed so that we could figure out what is going on.
Comment 19 Robin Bankhead 2024-08-18 20:52:26 UTC
Created attachment 172737 [details]
perf.data capture, xz-compressed (raw size 387MB)

The rebuilding isn't much of an issue, I just didn't want to do so on-spec without explicit direction to do so. Likewise I haven't done so for glibc but am happy to do so if needed.

I installed hotspot but with the additional symbols installed the "??" break down into several separate units so it seemed easier to re-run the capture so you can scrutinise it on your end, I hope that's OK. I can save the .perfparser file from hotspot and upload that instead if that's preferable and sufficient?
Comment 20 fanzhuyifan 2024-08-18 20:54:17 UTC
(In reply to Robin Bankhead from comment #19)

> I installed hotspot but with the additional symbols installed the "??" break
> down into several separate units so it seemed easier to re-run the capture
> so you can scrutinise it on your end, I hope that's OK. I can save the
> .perfparser file from hotspot and upload that instead if that's preferable
> and sufficient?

Yeah having the .perfparser file should be sufficient. Thanks again!
Comment 21 Robin Bankhead 2024-08-19 00:46:11 UTC
Created attachment 172739 [details]
perf.data.perfparser exported from hotspot, xz-compressed
Comment 22 fanzhuyifan 2024-08-19 02:00:34 UTC
(In reply to Robin Bankhead from comment #21)
> Created attachment 172739 [details]
> perf.data.perfparser exported from hotspot, xz-compressed

Thanks! 

It appears that a lot of time is spent doing context management in `QEventDispatcherGlib::processEvents`.

A suspicious entry is `socketNotifierSourceDispatch`. It would appear that kglobalacceld is getting a lot of SocketNotifier events. One way to confirm that would be to use Gammaray on kglobalacceld, and check the events.

The only place that kglobalacceld uses QSocketNotifier is using xcb record to listen to key and button presses and releases:
https://invent.kde.org/plasma/kglobalacceld/-/blob/master/src/plugins/xcb/kglobalaccel_x11.cpp?blame=0#L89

If things are working as intended, there should be 1 event for each key/button press/release, which should be quite reasonable. On my end, this indeed is the behavior, as I can verify through Gammaray. Currently I have no idea why we might be getting a flood of events on your end.
Comment 23 fanzhuyifan 2024-08-19 02:03:45 UTC
Downstream report: https://bugs.gentoo.org/935406
Comment 24 Robin Bankhead 2024-08-19 10:00:47 UTC
Could it have anything to do with dbus?

I can't resist the suspicion that openrc vs systemd lies at the root of the issue, and the logging shows a number of dbus-related complaints including this one that's repeated several times during session launch:

Couldn't start kglobalaccel from org.kde.kglobalaccel.service: QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name org.kde.kglobalaccel was not provided by any .service files")

A number of dbus-related things including polkit, pipewire and plasma-pa have issues in this session as well (although oddly, most do not occur if I launch vncserver directly as my user instead of by initscript).
Comment 25 fanzhuyifan 2024-08-19 16:36:55 UTC
(In reply to Robin Bankhead from comment #24)
> Could it have anything to do with dbus?

If my conjecture in https://bugs.kde.org/show_bug.cgi?id=489840#c22 is correct, then this probably has nothing to do with dbus. Instead, the issue might be in xvnc -- maybe the record extension doesn't work correctly in xvnc?
Comment 26 Robin Bankhead 2024-08-19 17:27:42 UTC
If that's the case then we may have run out of road here, because tigervnc only support systemd nowadays.

What I could do is solicit for Gentoo systemd+KDE users in the forums to see if the issue exists for them, but I am doubtful that it will as I've not seen this bug when the server runs under systemd on other distros.
Comment 27 fanzhuyifan 2024-08-19 17:29:42 UTC
(In reply to Robin Bankhead from comment #26)
> If that's the case then we may have run out of road here, because tigervnc
> only support systemd nowadays.
> 
> What I could do is solicit for Gentoo systemd+KDE users in the forums to see
> if the issue exists for them, but I am doubtful that it will as I've not
> seen this bug when the server runs under systemd on other distros.

I think it would be a good idea to first check with gammaray to see if indeed a flood of socketnotifier events is causing the issue.
Comment 28 Robin Bankhead 2024-08-19 19:46:07 UTC
Created attachment 172758 [details]
Screenshot of Gammaray attached to kglobalacceld in Xvnc session

Found it. Another KDAB app, do you work for them? ;-)

So it looks like your theory was correct. So does this confirm TigerVNC's Record extension impl is where the issue must lie?

[Please advise if you want any further things out of GammaRay.]
Comment 29 Robin Bankhead 2024-11-02 11:48:25 UTC
Now on plasma-6.2.2 and have noticed some change in behaviour.

1. Triggering has returned to on first manual keypress within the VNC client session, rather than immediately on client connect.

2. On killing and relaunching kglobalacceld, it is fully functional (for both built-in and user-defined shortcuts) and the other input-related corruptions mentioned in OP do not occur.

This effectively brings the behaviour back to its state circa plasma-5. Let me therefore bring in two further details from back then that were moot until now:

1. After relaunch, further (manual) keyboard input does not re-trigger the bug in any way that I've found so far.

2. The bug *can* be manually re-triggered using xdotool, e.g. "xdotool type helloworld". (Again, kill and relaunch of kglobalacceld recovers fully.)

From the discussion above, it sounds as though this may be more TigerVNC's bug to fix, but I am doubtful they will be very receptive to a non-systemd-user. If you have any thoughts on whether/how this can be pitched as an issue they should address irrespective of init system, I'd be grateful to hear them. The current easing of the symptoms means it can be worked-around and I can return to Plasma as my VNC daily-driver, but I'd still like to see this resolved once and for all.
Comment 30 Davide Favaro 2024-12-06 10:37:32 UTC
coss posting to #489840 and #306352 because I don't know which one is the correct one.
I have the same problem: remote TigerVNC session eating 100%. I have gentoo and plasma 6.2.4 with NO .xmod* files or folder (never had) and I'm on systemd.
Comment 31 Robin Bankhead 2024-12-11 12:26:11 UTC
(In reply to Davide Favaro from comment #30)
> coss posting to #489840 and #306352 because I don't know which one is the
> correct one.
> I have the same problem: remote TigerVNC session eating 100%. I have gentoo
> and plasma 6.2.4 with NO .xmod* files or folder (never had) and I'm on
> systemd.

Thanks Davide, this eliminates any possibility that absence of systemd was a factor. This can now be raised with TigerVNC team.

I wonder, though: We haven't seen anything similar happen with other desktops (Davide mentioned in forum that he had no issues with LxQt, and I've none on Fluxbox). We've seen that a flood of SocketNotifier events from Xvnc's RECORD extension is what causes kglobalacceld's problem (I hope I've described that accurately from what's been said above). But is it something unique to KDE that is in turn causing that flood to be generated?

If the same flood of events was happening in another desktop without kglobalacceld to act as "canary", would there be any way to tell? (Executing xdotool always triggers this bug under KDE, under Fluxbox I see no ill-effect.)