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 bu
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
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 her
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.
https://bugs.kde.org/show_bug.cgi?id=489840
Pierre Ossman changed:
What|Removed |Added
CC||oss...@cendio.se
--- Comment #32 from Pierre Os
https://bugs.kde.org/show_bug.cgi?id=489840
Robin Bankhead changed:
What|Removed |Added
See Also||https://github.com/TigerVNC
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
https://bugs.kde.org/show_bug.cgi?id=489840
belzeb...@gmail.com changed:
What|Removed |Added
CC||belzeb...@gmail.com
--- Comment #30 from b
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 r
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
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+
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,
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 w
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 repea
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.
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
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 bu
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
https://bugs.kde.org/show_bug.cgi?id=489840
Robin Bankhead changed:
What|Removed |Added
Attachment #172729|0 |1
is obsolete|
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/unregister
https://bugs.kde.org/show_bug.cgi?id=489840
fanzhuyi...@gmail.com changed:
What|Removed |Added
Resolution|WAITINGFORINFO |---
Status|NEEDSINFO
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 bu
https://bugs.kde.org/show_bug.cgi?id=489840
Robin Bankhead changed:
What|Removed |Added
Attachment #172536|0 |1
is obsolete|
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
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
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:
Y
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
https://bugs.kde.org/show_bug.cgi?id=489840
Robin Bankhead changed:
What|Removed |Added
Attachment #171431|0 |1
is obsolete|
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. Unfortu
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 prec
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 w
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
https://bugs.kde.org/show_bug.cgi?id=489840
fanzhuyi...@gmail.com changed:
What|Removed |Added
Status|REPORTED|NEEDSINFO
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=489840
Robin Bankhead changed:
What|Removed |Added
Resolution|WAITINGFORINFO |---
Status|NEEDSINFO
https://bugs.kde.org/show_bug.cgi?id=489840
Andreas Sturmlechner changed:
What|Removed |Added
CC||ast...@gentoo.org
--- Comment #4 from An
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
https://bugs.kde.org/show_bug.cgi?id=489840
fanzhuyi...@gmail.com changed:
What|Removed |Added
Status|REPORTED|NEEDSINFO
Resolution|---
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
38 matches
Mail list logo
