[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #44 from Robin Bankhead  ---
Ugh, apologies - the trigger is more general and appears to be the
xdg-desktop-portal-kde file dialog. Reliably triggering the bug in both Firefox
(when set to use portal filepicker) and KWrite. Specifically, when the dialog
is dismissed.

I'm sure I have used these dialogs previously without triggering the bug, so it
is either a new development brought by kde-6.5.2 (just upgraded from 6.4.4), or
(somehow) related to my recently installing flatpak (+ Libreoffice by that
format) for the first time. I only treat that as a possibility due to the
XDG/portal connection, which may be irrelevant.

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #43 from Robin Bankhead  ---
Just stumbled on another reliable trigger: Using a file-upload form field (with
some Javascript attached) in Firefox.

I haven't seen this anywhere else yet and the web code in question is private,
but I will see if I can debug it and produce a test case when time allows.

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #42 from Robin Bankhead  ---
Coming back for a second to having xdotool as a reliable trigger for the bug,
is there any way this fact can be leveraged?

It is a quite small library and wrapper exe, I'm just wondering if those with
trained eyes could suggest something specific that is done in common both when
invoking xdotool, and the first time a viewer attaches to a running server
session (how the bug initially strikes for me at present)?

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #41 from Robin Bankhead  ---
If you are talking C*FLAGS obviously being Gentoo we users set these
personally, mine are (for all *FLAGS)

-march=native -O2 -pipe -fomit-frame-pointer


While looking in the build log I also noted some warnings in what I take to be
keymapping-related code, sharing below in case relevant:

XKBMAlloc.c: In function 'SrvXkbChangeKeycodeRange':
XKBMAlloc.c:664:21: warning: pointer may be used after 'reallocarray'
[-Wuse-after-free]
  664 | free(prev_key_sym_map);
  | ^~
XKBMAlloc.c:660:41: note: call to 'reallocarray' here
  660 | xkb->map->key_sym_map =
reallocarray(xkb->map->key_sym_map,
  |
^~~
  661 |  maxKC + 1,
  |  ~~
  662 | 
sizeof(XkbSymMapRec));
  | 
~
XKBMAlloc.c:685:21: warning: pointer may be used after 'reallocarray'
[-Wuse-after-free]
  685 | free(prev_modmap);
  | ^
XKBMAlloc.c:681:36: note: call to 'reallocarray' here
  681 | xkb->map->modmap = reallocarray(xkb->map->modmap,
  |^~
  682 | maxKC + 1,
  | ~~
  683 | sizeof(unsigned char));
  | ~~
XKBMAlloc.c:708:21: warning: pointer may be used after 'reallocarray'
[-Wuse-after-free]
  708 | free(prev_behaviors);
  | ^~~~
XKBMAlloc.c:704:42: note: call to 'reallocarray' here
  704 | xkb->server->behaviors =
reallocarray(xkb->server->behaviors,
  | 
^~~~
  705 |   maxKC + 1,
  |   ~~
  706 |  
sizeof(XkbBehavior));
  |  

XKBMAlloc.c:730:21: warning: pointer may be used after 'reallocarray'
[-Wuse-after-free]
  730 | free(prev_key_acts);
  | ^~~
XKBMAlloc.c:726:41: note: call to 'reallocarray' here
  726 | xkb->server->key_acts =
reallocarray(xkb->server->key_acts,
  |
^~~
  727 |  maxKC + 1,
  |  ~~
  728 |  sizeof(unsigned
short));
  | 
~~~
XKBMAlloc.c:752:21: warning: pointer may be used after 'reallocarray'
[-Wuse-after-free]
  752 | free(prev_vmodmap);
  | ^~
XKBMAlloc.c:748:40: note: call to 'reallocarray' here
  748 | xkb->server->vmodmap =
reallocarray(xkb->server->vmodmap,
  |   
^~
  749 | maxKC + 1,
  | ~~
  750 | sizeof(unsigned
short));
  |
~~~
XKBMAlloc.c:774:17: warning: pointer may be used after 'reallocarray'
[-Wuse-after-free]
  774 | free(prev_keys);
  | ^~~
XKBMAlloc.c:771:32: note: call to 'reallocarray' here
  771 | xkb->names->keys = reallocarray(xkb->names->keys,
  |^~
  772 | maxKC + 1,
sizeof(XkbKeyNameRec));
  |
~

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #40 from Robin Bankhead  ---
Here is the configure line from my last build log. Can post the whole thing (or
snaffle temp files from an in-progress build) if it helps any.

./configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib
--datarootdir=/usr/share --disable-dependency-tracking --disable-silent-rules
--disable-static --docdir=/usr/share/doc/tigervnc-1.15.0
--htmldir=/usr/share/doc/tigervnc-1.15.0/html --with-sysroot=/
--libdir=/usr/lib64 --enable-glx --enable-libdrm --disable-config-hal
--disable-config-udev --disable-devel-docs --disable-dri --enable-dri3
--disable-glamor --disable-kdrive --disable-libunwind --disable-linux-acpi
--disable-record --disable-selective-werror --disable-static
--disable-unit-tests --disable-xephyr --disable-xinerama --disable-xnest
--disable-xorg --disable-xvfb --disable-xwin --enable-dri2 --with-pic
--without-dtrace --with-sha1=libcrypto

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[bugzilla_noreply]

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

--- Comment #39 from fanzhuyi...@gmail.com ---
Since this only happens on gentoo, maybe gentoo users could compare against
compilation options of other distros, and see if any compilation option of a
related package is causing the issue?

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #38 from Robin Bankhead  ---
The only spare units I have access to for testing are RPis. I can't reproduce
there with RpiOS Bullseye, which is on KDE5 (but thus in theory should also be
affected by this bug). If there is an OS for the Pi5 that would be useful for
testing I'm happy to give it a go.

That aside I'm also more than happy to attempt digging deeper into the
debugging effort begun above if any further instruction can be offered.

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Pierre Ossman]

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

--- Comment #37 from Pierre Ossman  ---
Has anyone had any luck getting a test case on something like Fedora or Ubuntu?
I'd like to help debug this, but going through all the steps to set up Gentoo
for that is a bit much.

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[bugzilla_noreply]

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

fanzhuyi...@gmail.com changed:

   What|Removed |Added

   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=490985

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #36 from Robin Bankhead  ---
I just reviewed this report's sort-of precursor [1] - which I had been
reluctant to add here as it's quite a mess and petered out - and out of those
commenters there who I think likely to actually have the same bug, those who
mentioned a distro were all Gentoo or Exherbo (which is also source-based -
relevant?). One of the much earlier postings, from kde4 era (!) was on Kubuntu
but I have some suspicion that that was not the same bug (VNC not mentioned,
trigger was system resume).

[1] https://bugs.kde.org/show_bug.cgi?id=306352

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Pierre Ossman]

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

--- Comment #35 from Pierre Ossman  ---
Sounds like your versions are reasonably close, so I agree that it is unlikely
that will resolve things.

The question is then what differs between my system and yours. I'm on Fedora
41, so there are lots of subtle differences compare to Gentoo.

Has anyone seen this issue outside of Gentoo systems? Perhaps they are doing
something custom to their Xorg code?

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #34 from Robin Bankhead  ---
(In reply to Pierre Ossman from comment #32)
> TigerVNC developer here, trying to have a look at this.
> 
> (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.
> 
> I'd like to start with clearing up this misunderstanding. We don't have a
> strict requirement on systemd, but I can understand the confusion.
> 
> We only support the components that are included with TigerVNC. One such
> component is the "vncserver" service, which is used to start sessions.
> Starting desktop environments is hard, and easy to get wrong. We don't have
> the resources to help out with other software that starts desktops. E.g. old
> school "vncserver" commands that the user runs when already in an existing
> session.
> 
> Other components of TigerVNC has nothing to do with this and are supported
> on their own merits. E.g. the "Xvnc" component, which seems to be the
> relevant one here. At that point, it's up to you how you launch your desktop
> and applications. Just as long as you don't expect us to support those as
> well. We'll gladly help out with issues with Xvnc, but not the complexities
> beyond that.
> 
> For the issue at hand, it seems to be an X11 interaction issue. So it falls
> under what Xvnc is supposed to do.
> 
> That said, the X11 code is 99% just standard Xorg. So usually, the issues
> need to be resolved there.
> 

Thanks for looking in, Pierre. Apologies if I misinterpreted the position: I
was drawing on your comments on your tracker [1] and the deprecation of the
`vncserver` Perl script that seemed to indicate that the systemd (system)
service would be the only mode of operation you'd be supporting. I follow your
reasoning above but from my POV a systemd service environment is very different
from an OpenRC one, and in any case as you'll see above it's only quite
recently that we obtained the debugging that gave me something substantive to
bring to your door.

> I tried to reproduce the problem here, but was unable to. I am running
> Plasma 6.2.5, and an Xvnc based on Xorg server 21.1.8.
> 
> Could this issue already be resolved with sufficiently new versions of
> things? Could someone test with those newer versions?

Current Gentoo packaging of tigervnc-1.14.1 is built against xserver-21.1.14.
We have a live ebuild (built from git) but that also currently builds against
21.1.14. As for KDE I am currently at 6.2.4 but 6.2.5 is available, I may get
time at the weekend to update (takes a while on Gentoo, y'know...)

Given that I've been aware of this bug since mid-2022 (and it may have existed
in some form back as far as 2012) my hopes are not super high of a happy
accident resolving it this time around, but we'll see.

[1] https://github.com/TigerVNC/tigervnc/issues/1096

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Pierre Ossman]

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

--- Comment #33 from Pierre Ossman  ---
(In reply to Pierre Ossman from comment #32)
> I tried to reproduce the problem here, but was unable to. I am running
> Plasma 6.2.5, and an Xvnc based on Xorg server 21.1.8.

Sorry, it was actually Xorg server 22.1.14.

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Pierre Ossman]

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

Pierre Ossman  changed:

   What|Removed |Added

 CC||oss...@cendio.se

--- Comment #32 from Pierre Ossman  ---
TigerVNC developer here, trying to have a look at this.

(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.

I'd like to start with clearing up this misunderstanding. We don't have a
strict requirement on systemd, but I can understand the confusion.

We only support the components that are included with TigerVNC. One such
component is the "vncserver" service, which is used to start sessions. Starting
desktop environments is hard, and easy to get wrong. We don't have the
resources to help out with other software that starts desktops. E.g. old school
"vncserver" commands that the user runs when already in an existing session.

Other components of TigerVNC has nothing to do with this and are supported on
their own merits. E.g. the "Xvnc" component, which seems to be the relevant one
here. At that point, it's up to you how you launch your desktop and
applications. Just as long as you don't expect us to support those as well.
We'll gladly help out with issues with Xvnc, but not the complexities beyond
that.

For the issue at hand, it seems to be an X11 interaction issue. So it falls
under what Xvnc is supposed to do.

That said, the X11 code is 99% just standard Xorg. So usually, the issues need
to be resolved there.

I tried to reproduce the problem here, but was unable to. I am running Plasma
6.2.5, and an Xvnc based on Xorg server 21.1.8.

Could this issue already be resolved with sufficiently new versions of things?
Could someone test with those newer versions?

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

Robin Bankhead  changed:

   What|Removed |Added

   See Also||https://github.com/TigerVNC
   ||/tigervnc/issues/1890

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #31 from Robin Bankhead  ---
(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.)

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[bugzilla_noreply]

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

belzeb...@gmail.com changed:

   What|Removed |Added

 CC||belzeb...@gmail.com

--- Comment #30 from belzeb...@gmail.com ---
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.

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #29 from Robin Bankhead  ---
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.

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #28 from Robin Bankhead  ---
Created attachment 172758
  --> https://bugs.kde.org/attachment.cgi?id=172758&action=edit
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.]

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[bugzilla_noreply]

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

--- Comment #27 from fanzhuyi...@gmail.com ---
(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.

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #26 from Robin Bankhead  ---
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.

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[bugzilla_noreply]

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

--- Comment #25 from fanzhuyi...@gmail.com ---
(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?

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #24 from Robin Bankhead  ---
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).

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[bugzilla_noreply]

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

--- Comment #23 from fanzhuyi...@gmail.com ---
Downstream report: https://bugs.gentoo.org/935406

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[bugzilla_noreply]

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

--- Comment #22 from fanzhuyi...@gmail.com ---
(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.

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #21 from Robin Bankhead  ---
Created attachment 172739
  --> https://bugs.kde.org/attachment.cgi?id=172739&action=edit
perf.data.perfparser exported from hotspot, xz-compressed

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[bugzilla_noreply]

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

--- Comment #20 from fanzhuyi...@gmail.com ---
(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!

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

Robin Bankhead  changed:

   What|Removed |Added

 Attachment #172729|0   |1
is obsolete||

--- Comment #19 from Robin Bankhead  ---
Created attachment 172737
  --> https://bugs.kde.org/attachment.cgi?id=172737&action=edit
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?

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[bugzilla_noreply]

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

--- Comment #18 from fanzhuyi...@gmail.com ---
Created attachment 172732
  --> https://bugs.kde.org/attachment.cgi?id=172732&action=edit
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.

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[bugzilla_noreply]

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

fanzhuyi...@gmail.com changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |---
 Status|NEEDSINFO   |REPORTED

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #17 from Robin Bankhead  ---
Created attachment 172729
  --> https://bugs.kde.org/attachment.cgi?id=172729&action=edit
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).

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

Robin Bankhead  changed:

   What|Removed |Added

 Attachment #172536|0   |1
is obsolete||

--- Comment #16 from Robin Bankhead  ---
Created attachment 172567
  --> https://bugs.kde.org/attachment.cgi?id=172567&action=edit
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.

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #15 from Robin Bankhead  ---
(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?

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #14 from Robin Bankhead  ---
(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 
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:
.
Find the GDB manual and other documentation resources online at:
.

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".
0x7f9fc6668180 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  0x7f9fc6d2266f in poll () at /lib64/libc.so.6
#1  0x7f9fc666b8d7 in ??? () at /usr/lib64/libglib-2.0.so.0
#2  0x7f9fc666bfa0 in g_main_context_iteration () at
/usr/lib64/libglib-2.0.so.0
#3  0x7f9fc72c1670 in
QEventDispatcherGlib::processEvents(QFlags) ()
at /usr/lib64/libQt6Core.so.6
#4  0x7f9fc750f2aa in
QEventLoop::exec(QFlags) () at
/usr/lib64/libQt6Core.so.6
#5  0x7f9fc744c8c0 in QThread::exec() () at /usr/lib64/libQt6Core.so.6
#6  0x7f9fc6a65b8e in ??? () at /usr/lib64/libQt6DBus.so.6
#7  0x7f9fc73ee76a in ??? () at /usr/lib64/libQt6Core.so.6
#8  0x7f9fc6cc3379 in ??? () at /lib64/libc.so.6
#9  0x7f9fc6d2f2cc in ??? () at /lib64/libc.so.6

Thread 2 (Thread 0x7f9fc16006c0 (LWP 3028) "QXcbEventQueue"):
#0  0x7f9fc6d2266f in poll () at /lib64/libc.so.6
#1  0x7f9fc5b1c4a2 in ??? () at /usr/lib64/libxcb.so.1
#2  0x7f9fc5b1e86a in xcb_wait_for_event () at /usr/lib64/libxcb.so.1
#3  0x7f9fc2d7b418 in ??? () at
/usr/lib64/qt6/plugins/platforms/../../../libQt6XcbQpa.so.6
#4  0x7f9fc73ee76a in ??? () at /usr/lib64/libQt6Core.so.6
#5  0x7f9fc6cc3379 in ??? () at /lib64/libc.so.6
#6  0x7f9fc6d2f2cc in ??? () at /lib64/libc.so.6

Thread 1 (Thread 0x7f9fc2ddce40 (LWP 3000) "kglobalacceld"):
#0  0x7f9fc6668180 in ??? () at /usr/lib64/libglib-2.0.so.0
#1  0x7f9fc6669fed in ??? () at /usr/lib64/libglib-2.0.so.0
#2  0x7f9fc666b4dc in ??? () at /usr/lib64/libglib-2.0.so.0
#3  0x7f9fc666b816 in ??? () at /usr/lib64/libglib-2.0.so.0
#4  0x7f9fc666bfa0 in g_main_context_iteration () at
/usr/lib64/libglib-2.0.so.0
#5  0x7f9fc72c1670 in
QEventDispatcherGlib::processEvents(QFlags) ()
at /usr/lib64/libQt6Core.so.6
#6  0x7f9fc750f2aa in
QEventLoop::exec(QFlags) () at
/usr/lib64/libQt6Core.so.6
#7  0x7f9fc750f45a in QCoreApplication::exec() () at
/usr/lib64/libQt6Core.so.6
#8  0x558d983bfa9c 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).

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[bugzilla_noreply]

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

--- Comment #13 from fanzhuyi...@gmail.com ---
Also, could you install debug symbols for kglobalacceld, run "perf record -p
 --call-graph dwarf", wait for ~10s, press Ctrl-C, and
upload the resulting perf.data?

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[bugzilla_noreply]

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

--- Comment #12 from fanzhuyi...@gmail.com ---
(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

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

Robin Bankhead  changed:

   What|Removed |Added

 Attachment #171431|0   |1
is obsolete||

--- Comment #11 from Robin Bankhead  ---
Created attachment 172536
  --> https://bugs.kde.org/attachment.cgi?id=172536&action=edit
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.

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[bugzilla_noreply]

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

--- Comment #10 from fanzhuyi...@gmail.com ---
(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.

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #9 from Robin Bankhead  ---
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?

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[bugzilla_noreply]

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

--- Comment #8 from fanzhuyi...@gmail.com ---
(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

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #7 from Robin Bankhead  ---
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

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[bugzilla_noreply]

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

fanzhuyi...@gmail.com changed:

   What|Removed |Added

 Status|REPORTED|NEEDSINFO
 Resolution|--- |WAITINGFORINFO

--- Comment #6 from fanzhuyi...@gmail.com ---
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!

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

Robin Bankhead  changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |---
 Status|NEEDSINFO   |REPORTED

--- Comment #5 from Robin Bankhead  ---
Rebuilt kglobalacceld-6.1.2 with the patch from comment #2 applied. No change
in bug behaviour :(

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Andreas Sturmlechner]

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

Andreas Sturmlechner  changed:

   What|Removed |Added

 CC||ast...@gentoo.org

--- Comment #4 from Andreas Sturmlechner  ---
(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

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #3 from Robin Bankhead  ---
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).

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[bugzilla_noreply]

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

fanzhuyi...@gmail.com changed:

   What|Removed |Added

 Status|REPORTED|NEEDSINFO
 Resolution|--- |WAITINGFORINFO
 CC||fanzhuyi...@gmail.com
   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=306352

--- Comment #2 from fanzhuyi...@gmail.com ---
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.

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

[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session

[Robin Bankhead]

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

--- Comment #1 from Robin Bankhead  ---
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.)

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