[plasmashell] [Bug 370924] New: Brightness slider slowly "moving back" after dragging the slider thumb.

[Rob via KDE Bugzilla]

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

Bug ID: 370924
   Summary: Brightness slider slowly "moving back" after dragging
the slider thumb.
   Product: plasmashell
   Version: 5.8.0
  Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Battery Monitor
  Assignee: k...@privat.broulik.de
  Reporter: r...@robwu.nl
CC: plasma-b...@kde.org

Steps to reproduce:
1. Open the battery monitor widget.
2. Click at the left side of the slider to set the initial position of the
slider.
3. Wait until the brightness has changed.
4. Grab the slider thumb with the mouse, and move it to the right.

Expected:
- Upon releasing the thumb, the screen should be at its brightest setting.

Actual:
- Upon releasing the thumb, the screen is at its brightest setting (so far so
good)
- AND the brightness slowly drops, while the thumb slowly moves to the left.

More info:
- When I drag the slider a couple of times back and forwards, and *click* on a
point in the slider where it is moving from, then the brightness (and slider
thumb) quickly switches to that setting (as expected). But within a split
second, the thumb (and brightness level) jumps back to their previous position.

While testing this, I was utilizing 100% of my CPU (compiling), so that might
have impacted the test results.

I am not very familiar with QML, but from inspection of
applets/batterymonitor/package/contents/ui/PopupDialog.qml, it seems that there
is a feedback loop between setting the attribute and updating the value again,
which only ends when the brightness values have converged to the same value.
When I use the mouse to drag the thumb on the slider, then I probably trigger
multiple brightnessSlider value change events, which in their turn trigger the
slide value change events again (I guess?).

brightnessSlider.valueChanged.connect(function() {
batterymonitor.screenBrightness = brightnessSlider.value
(...)
BrightnessItem {
id: brightnessSlider
(...)
Connections {
target: batterymonitor
onScreenBrightnessChanged: brightnessSlider.value =
batterymonitor.screenBrightness

Code snippets from:
https://quickgit.kde.org/?p=plasma-workspace.git=blob=cd92a28ca64af518409adbad9d5fb3eeebd59a1c=e7a07a154006a270149d78eeb2abd114b5ab816a=applets%2Fbatterymonitor%2Fpackage%2Fcontents%2Fui%2FPopupDialog.qml#l42

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

[plasmashell] [Bug 370003] Performance issues (laggy animations, stuttering keyboard input handling, severe frame drops in videos) after using plasmashell for a few days

[Rob via KDE Bugzilla]

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

--- Comment #3 from Rob  ---
One of the issues is that animations is slow. Switching desktops includes an
animation (the cube animation in my case), hence I used that as a test.

I don't know whether the observation in the perf recording is related to my
issue (I think it does, but I would not be surprised if it is not).

My actual CPU usage is far from 100%, so this is probably different from bug
356479.

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

[plasmashell] [Bug 370003] Performance issues (laggy animations, stuttering keyboard input handling, severe frame drops in videos) after using plasmashell for a few days

[Rob via KDE Bugzilla]

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

--- Comment #1 from Rob  ---
Created attachment 101422
  --> https://bugs.kde.org/attachment.cgi?id=101422=edit
perf record -e cpu-clock  -p `pidof plasmashell` # After restarting plasmashell

For comparison, this is what I get right when I switch desktops (5x) after
restarting plasmashell. The excessive time spent in locks is absent in this
recording.

Usage:

$ perf report -i perf.data

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

[kstars] [Bug 362822] KStars receives segfault in libqcxb when I close my laptop lid

[Rob via KDE Bugzilla]

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

--- Comment #2 from Rob  ---
Thanks Jasem. For now I've set IgnoreLid=true in /etc/UPower/Upower.conf and
that's a sufficient workaround for me.

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

[kstars] [Bug 362822] New: KStars receives segfault in libqcxb when I close my laptop lid

[Rob via KDE Bugzilla]

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

Bug ID: 362822
   Summary: KStars receives segfault in libqcxb when I close my
laptop lid
   Product: kstars
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: mutla...@ikarustech.com
  Reporter: kst...@meades.org

I'm using KStars bleeding (help says Version 2.6.0), updated today, and I've
found that KStars now crashes when I close the lid of my laptop, see journal
output below.  I've been doing various installations/removals so it's possible
I've messed something up, but KStars wasn't doing this yesterday:

May 08 17:55:21 rob-Latitude-D830 systemd-logind[610]: Lid closed.
May 08 17:55:21 rob-Latitude-D830 cpufreqd[676]: get_class_device_attribute:
couldn't open
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/energy_full
(No such file or directory)
May 08 17:55:21 rob-Latitude-D830 cpufreqd[676]: get_class_device_attribute:
couldn't open
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/energy_now
(No such file or directory)
May 08 17:55:21 rob-Latitude-D830 cpufreqd[676]: get_class_device_attribute:
couldn't open
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/power_now (No
such file or directory)
May 08 17:55:22 rob-Latitude-D830 kernel: show_signal_msg: 30 callbacks
suppressed
May 08 17:55:22 rob-Latitude-D830 kernel: kstars[1731]: segfault at 20 ip
7f8a517e0e3b sp 7ffdb0796908 error 4 in libqxcb.so[7f8a517b2000+b5000]
May 08 17:55:26 rob-Latitude-D830 systemd-logind[610]: Lid opened.

Any idea what I might have done to cause this?

Rob

Reproducible: Always

Steps to Reproduce:
1. Start KStars
2. Close laptop lid


Expected Results:  
KStars to remain unaffected.

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

[kstars] [Bug 361646] KStars hogs CPU until unusable

[Rob via KDE Bugzilla]

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

--- Comment #23 from Rob  ---
OK, I think I have confirmed to my satisfaction that there are two things going
on here:

1.  My laptop sometimes suffers from a generic slow-down which seems to be
connected with the fan not running aggressively enough.  Looking at the core
temperatures they don't _seem_ excessive (not much more than 60 C worst case)
but running the fans more aggressively seems to have removed that problem.

2.  Irrespective of (1), if I tell KStars to get time/location etc. from the
device rather than from the computer then, sometimes immediately, sometimes
after a little while, KStars slowly starts to freeze up.  I can see CPU usage
start pulsing to max and then I can see 100% of one CPU used, etc.  Maybe some
sort of beating going on as clocks slip?  Or maybe something wrong in my EQMod
driver configuration?

Anyway, unless you want me to do more experimentation, I'm happy with the
workaround of setting KStars to use the computer for time/location as that is
more natural for me in any case.

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

[kstars] [Bug 361646] KStars hogs CPU until unusable

[Rob via KDE Bugzilla]

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

--- Comment #22 from Rob  ---
I've not reached a conclusion yet, but results so far suggest:

- the latest KStars may be slightly better but the slow down is still there
(sorry!)
- switching off as much OpenGL as I can in the video driver doesn't help
- pausing the KStars clock at launch doesn't help
- I needed to increase the speed/use of my CPU fan to keep improve laptop
performance in general

That said, I've now performed four sessions, rebooting inbetween, without a
slow down and the only difference is that setting in KStars to use the computer
for time/location etc. rather than the devices.

I'm going to leave it running for the evening and then I will try switching
KStars back to using device for time/location to see if the problem then comes
back.

KStars/Ekos/Indi is sooo sweet with this problem resolved, I'm really looking
forward to using it for real. :-)

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

[kstars] [Bug 361646] KStars hogs CPU until unusable

[Rob via KDE Bugzilla]

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

--- Comment #20 from Rob  ---
Ah, yes, got it now, testing...

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

[kstars] [Bug 361646] KStars hogs CPU until unusable

[Rob via KDE Bugzilla]

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

--- Comment #18 from Rob  ---
Hi Jasem.  I tried

sudo apt-get install kstars-bleeding

...last night but no update.  Should I have seen one?

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

[kstars] [Bug 361646] KStars hogs CPU until unusable

[Rob via KDE Bugzilla]

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

--- Comment #17 from Rob  ---
That's excellent news, I'll update tomorrow and let you know how it goes.

Many thanks.

Rob

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

[kstars] [Bug 361646] KStars hogs CPU until unusable

[Rob via KDE Bugzilla]

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

--- Comment #15 from Rob  ---
Created attachment 98676
  --> https://bugs.kde.org/attachment.cgi?id=98676=edit
Normal case for comparison

This is a normal case, no EKOS window freezing, for comparison.

Note that I'm not at all sure that these frozen windows are exactly the same as
the slow-down I saw originally.

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

[kstars] [Bug 361646] KStars hogs CPU until unusable

[Rob via KDE Bugzilla]

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

--- Comment #14 from Rob  ---
Created attachment 98675
  --> https://bugs.kde.org/attachment.cgi?id=98675=edit
EKOS window freezes 2

This is another case of the same EKOS window freezing, captured in the same
way.

Rob

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

[kstars] [Bug 361646] KStars hogs CPU until unusable

[Rob via KDE Bugzilla]

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

--- Comment #13 from Rob  ---
Created attachment 98674
  --> https://bugs.kde.org/attachment.cgi?id=98674=edit
EKOS window freezes 1

OK, let's try a different attack.  The attached callgrind output was taken as
follows:

- Run kstars with Valgrind but with callgrind instrumentation off (valgrind
--tool=callgrind --instr-atstart=no kstars)
- Use kstars and find that Ekos window freezes up; I can't cause close it or
cause other dialogue boxes to appear
- Switch on callgrind instrumentation (callgrind_control -i on)
- Wait a few seconds and switch callgrind instrumentation off
(callgrind_control -i off)

Rob

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

[kstars] [Bug 361646] KStars hogs CPU until unusable

[Rob via KDE Bugzilla]

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

--- Comment #12 from Rob  ---
Created attachment 98568
  --> https://bugs.kde.org/attachment.cgi?id=98568=edit
HTMesh_performIntersection callgraph

One thing: RangeConvex::testTrixel() seems to be recursive: surely that's not
good?

Rob

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

[kstars] [Bug 361646] KStars hogs CPU until unusable

[Rob via KDE Bugzilla]

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

--- Comment #11 from Rob  ---
In case there is anything that looks unusual, I do still have the callgrind
output loaded in kcachegrind and i will [attempt to remember to] not close
kcachegrind or shut down the computer...!

Rob

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

[kstars] [Bug 361646] KStars hogs CPU until unusable

[Rob via KDE Bugzilla]

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

--- Comment #10 from Rob  ---
Created attachment 98554
  --> https://bugs.kde.org/attachment.cgi?id=98554=edit
kcachegrind screenshots for each item > 20% (part 2)

Detailed views for each kstars element in the callgrind tree above 20% (part
2).

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

[kstars] [Bug 361646] KStars hogs CPU until unusable

[Rob via KDE Bugzilla]

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

--- Comment #9 from Rob  ---
Created attachment 98553
  --> https://bugs.kde.org/attachment.cgi?id=98553=edit
kcachegrind screenshots for each item > 20% (part 1)

Detailed views for each kstars element in the callgrind tree above 20% (part
1).

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

[kstars] [Bug 361646] KStars hogs CPU until unusable

[Rob via KDE Bugzilla]

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

--- Comment #8 from Rob  ---
Created attachment 98552
  --> https://bugs.kde.org/attachment.cgi?id=98552=edit
kcachegrind overview

The top-level view from kcachegrind of the callgrind tree.  Detailed views for
each kstars element above the 20% mark follows.

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

[kstars] [Bug 361646] KStars hogs CPU until unusable

[Rob via KDE Bugzilla]

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

--- Comment #7 from Rob  ---
Above I've added a callgraph that was generated as follows:

- Clean reboot of computer
- Start kstars under callgrind to generate a callgrind log
- Wait for it to get to about 20% loaded NGIC/IC objects
- Give up 'cos I know it's going to take too long running this way
- Now start kstars in the normal way and find that it is running very slowly
- Use kcachegrind to generate the call tree.

Now of course this may not necessarily be the case in question but it is most
definitely a slow-down and it definitely occurred while starting kstars.

Unfortunately I managed to delete the callgrind file while attempting to zip it
(:-() so I only have the call tree above and, I will next load, a screenshot
from  kcachegrind.

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

[kstars] [Bug 361646] KStars hogs CPU until unusable

[Rob via KDE Bugzilla]

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

--- Comment #6 from Rob  ---
Created attachment 98551
  --> https://bugs.kde.org/attachment.cgi?id=98551=edit
Callgraph for KStars when in "slow down" state

This is a callgraph output from kcachegrind after I loaded it with callgrind
output from a session where kstars was started off and got into it's "slow"
state.

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

[kstars] [Bug 361646] KStars hogs CPU until unusable

[Rob via KDE Bugzilla]

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

--- Comment #5 from Rob  ---
Thanks for the comments guys.  I agree that this is likely some interaction
with the graphics driver.  I suggest that we keep this open while I experiment
with settings so that we can track the resolution here.  I'll also see if I can
find the simulation clock in the settings and get valgrind running.  It will
take a little time to do, hopefully I'll get back with more information next
week.

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

[kstars] [Bug 361646] KStars hogs CPU until unusable

[Rob via KDE Bugzilla]

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

--- Comment #2 from Rob  ---
FYI, I've tried disabling all OpenGL items in the NVidia X Server Settings
dialogue and selecting "High Performance" for the image settings rather than
"Quality", then rebooting.  I've also tried switching off stars, planets and
deep-sky objects in the KStars screen so that it is just ground and black sky. 
Nothing makes a difference so far.

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

[kstars] [Bug 361646] KStars hogs CPU until unusable

[Rob via KDE Bugzilla]

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

Rob  changed:

   What|Removed |Added

   Keywords||reproducible, usability

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

[kstars] [Bug 361646] New: KStars hogs CPU until unusable

[Rob via KDE Bugzilla]

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

Bug ID: 361646
   Summary: KStars hogs CPU until unusable
   Product: kstars
   Version: unspecified
  Platform: Ubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: mutla...@ikarustech.com
  Reporter: kst...@meades.org

I'm running KStars (v.2.5.0 with KDE Frameworks 5.9.0) as a client on Xubuntu
(15.10) on a Dell Latitude D830 laptop.  When KStars is first launched the
kstars process consumes ~15% (according to 'top') and KStars is very usable. 
However, after about 10 minutes of normal operation (doing nothing other than
scrolling around the KStars sky and looking at stuff), KStars starts hogging
CPU, getting to between 60% and 80%; the lag makes it pretty much unusable at
the point.  The laptop has Intel Core 2 Duo T7100/1.8 GHz processors and 4
Gbytes RAM. The RAM is never more than half used, the swap file is unused. I am
running the correct NVIDIA drivers for the graphics card.

When it gets into this state only a reboot will fix it.  If I just close and
restart KStars it takes a very long time to load and the kstars process still
consumes between 60% and 80% of CPU when just sitting there idle.

I'm very happy if there's a workaround or some tuning required for this: I
really want to use KStars!

Reproducible: Always

Steps to Reproduce:
1.  Start kstars.
2.  Scroll around looking at the sky for more than 10 minutes.
3. Wait for things to slow down.

Actual Results:  
The kstars process was using between %60 and %80 of CPU and the lag caused it
to be unusable.

Expected Results:  
The kstars process to consistently consume no more than 20% to 30% CPU when
idle.

The processing system has Intel Core 2 Duo T7100/1.8 GHz processors and 4
Gbytes RAM. The RAM is never more than half used, the swap file is unused. I am
running the correct NVIDIA drivers for the graphics card (nvidia-340).

My intention is to use Ekos as a client with remote Indi but the above happens
without any of that running.

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

[kmid] [Bug 359424] New: KMid crashes on opening some MIDI files

[Rob via KDE Bugzilla]

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

Bug ID: 359424
   Summary: KMid crashes on opening some MIDI files
   Product: kmid
   Version: 2.4.0
  Platform: openSUSE RPMs
OS: Linux
Status: UNCONFIRMED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: unassigned-b...@kde.org
  Reporter: ro...@lenkeninternational.co.uk

Application: kmid (2.4.0)
KDE Platform Version: 4.14.9
Qt Version: 4.8.6
Operating System: Linux 3.16.7-32-desktop x86_64
Distribution: "openSUSE 13.2 (Harlequin) (x86_64)"

-- Information about the crash:
Load QSynth
Open MIDI file with KMid, either directly or via Dolphin
KMid crashes immediately on opening file.

Notes:
1. This is 100% reproducible for certain MIDI files, but there is no problem
with the great majority of MIDI files.
2. These files were created in Rosegarden and play perfectly in that program. 
Many other files also created in Rosegarden are no problem with KMid.

The crash can be reproduced every time.

-- Backtrace:
Application: KMid (kmid), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fc7cb3157c0 (LWP 4064))]

Thread 3 (Thread 0x7fc7b99f9700 (LWP 4065)):
#0  0x7fc7c7b53d2d in read () at /lib64/libc.so.6
#1  0x7fc7c4d35750 in  () at /usr/lib64/libglib-2.0.so.0
#2  0x7fc7c4cf4714 in g_main_context_check () at
/usr/lib64/libglib-2.0.so.0
#3  0x7fc7c4cf4b7b in  () at /usr/lib64/libglib-2.0.so.0
#4  0x7fc7c4cf4cec in g_main_context_iteration () at
/usr/lib64/libglib-2.0.so.0
#5  0x7fc7c87f20de in
QEventDispatcherGlib::processEvents(QFlags) ()
at /usr/lib64/libQtCore.so.4
#6  0x7fc7c87c3e6f in
QEventLoop::processEvents(QFlags) () at
/usr/lib64/libQtCore.so.4
#7  0x7fc7c87c4165 in
QEventLoop::exec(QFlags) () at
/usr/lib64/libQtCore.so.4
#8  0x7fc7c86c10bf in QThread::exec() () at /usr/lib64/libQtCore.so.4
#9  0x7fc7c87a5783 in  () at /usr/lib64/libQtCore.so.4
#10 0x7fc7c86c379f in  () at /usr/lib64/libQtCore.so.4
#11 0x7fc7c5e360a4 in start_thread () at /lib64/libpthread.so.0
#12 0x7fc7c7b6008d in clone () at /lib64/libc.so.6

Thread 2 (Thread 0x7fc7b3fff700 (LWP 4066)):
#0  0x7fc7c7b57c5d in poll () at /lib64/libc.so.6
#1  0x7fc7b890c625 in drumstick::MidiClient::SequencerInputThread::run() ()
at /usr/lib64/libdrumstick-alsa.so.0
#2  0x7fc7c86c379f in  () at /usr/lib64/libQtCore.so.4
#3  0x7fc7c5e360a4 in start_thread () at /lib64/libpthread.so.0
#4  0x7fc7c7b6008d in clone () at /lib64/libc.so.6

Thread 1 (Thread 0x7fc7cb3157c0 (LWP 4064)):
[KCrash Handler]
#5  0x7fc7c8f65c94 in  () at /usr/lib64/libkdecore.so.5
#6  0x7fc7c8f67182 in  () at /usr/lib64/libkdecore.so.5
#7  0x7fc7c8f68514 in  () at /usr/lib64/libkdecore.so.5
#8  0x7fc7c8f638c6 in KEncodingProber::feed(char const*, int) () at
/usr/lib64/libkdecore.so.5
#9  0x7fc7b8dddbdc in  () at /usr/lib64/kde4/kmid_alsa.so
#10 0x7fc7b8dd2c8c in  () at /usr/lib64/kde4/kmid_alsa.so
#11 0x004283ad in _start ()

Reported using DrKonqi

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

[plasmashell] [Bug 359066] New: Plasma workspace freezes for 10 seconds upon selecting text in an untrusted X11 session (e.g. ssh -X)

[Rob via KDE Bugzilla]

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

Bug ID: 359066
   Summary: Plasma workspace freezes for 10 seconds upon selecting
text in an untrusted X11 session (e.g. ssh -X)
   Product: plasmashell
   Version: 5.5.3
  Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: k...@davidedmundson.co.uk
  Reporter: r...@robwu.nl
CC: bhus...@gmail.com, plasma-b...@kde.org

Created attachment 97046
  --> https://bugs.kde.org/attachment.cgi?id=97046=edit
xscope output recording the events around text selection

After starting an untrusted X11 session (with the Security Extension enabled),
selecting text (=putting text on the PRIMARY clipboard) causes the plasma
workspace (taskbar, clock, desktops, desktop widgets, etc) to freeze and become
non-responsive to input for ten seconds.

In addition to the above, if I then try to READ from the clipboard (e.g. by
selecting text in another program, or using xsel), then the program that
initiates the clipboard read request freezes as well.

If I use "ssh -Y" instead of "ssh -X" (or "xauth -f /tmp/myauthfile generate :0
. trusted" instead of "untrusted"), then the problem does not occur.

Steps to reproduce:
1. Set up an untrusted X11 forwarding session, e.g. via "ssh -X localhost" (or
via xauth)
2. Open a program with text input, e.g. "kdialog --textinputbox x y"
3. Select text with the mouse
4. Release the mouse
5. Open the terminal and run xsel (OR go to a GUI program like Firefox or
Chrome and try to paste the contents of PRIMARY via the mousewheel).

Actual result:
After step 4, the plasma workspace is frozen for 10 (ten) seconds (can't
interact with taskbar, clock isn't ticking, etc.).

At step 5, xsel does not immediately return the clipboard (it does not exit
until I press ^C, I waited for at least one minute) (if you try to paste in a
GUI program, the program freezes)

Expected result:
At step 4 and 5, the UI should never freeze and become non-responsive.
At step 5, xsel should immediately return (might be a bug in xsel?).

Additional information:
I recorded the data over the X11 protocol using xscope and attached a fragment
as x11-select-freeze.log (cutting the head and tail of the logs, but anything
in between is not modified).
It shows that the ChangeProperty request was rejected with Access error. The
stderr of the original program (kdialog) shows a similar issue:
X Error: BadAccess (attempt to access private resource denied) 10
  Major opcode: 18 (X_ChangeProperty)
  Resource id:  0x4c0003f

Based on the above information, I think that the request was generated by
QXcbClipboard::sendSelection.


Here is the stack trace of the thread that seems to be busy when plasmashell is
frozen. I captured it right after step 4 using
$ sudo gdb -q -p `pidof plasmashell` -batch -ex 'thread apply all bt'

Thread 1 (Thread 0x7f3fe1021800 (LWP 29489)):
#0  0x7f3fdb65fe23 in select () from /usr/lib/libc.so.6
#1  0x7f3fcd7b8de0 in ?? () from /usr/lib/libQt5XcbQpa.so.5
#2  0x7f3fcd7b93ff in ?? () from /usr/lib/libQt5XcbQpa.so.5
#3  0x7f3fcd7baf00 in ?? () from /usr/lib/libQt5XcbQpa.so.5
#4  0x7f3fdc2795a9 in QInternalMimeData::formats() const () from
/usr/lib/libQt5Gui.so.5
#5  0x7f3f20caf700 in ?? () from
/usr/lib/qt/plugins/plasma/dataengine/plasma_engine_clipboard.so
#6  0x7f3fdbf591a7 in QMetaObject::activate(QObject*, int, int, void**) ()
from /usr/lib/libQt5Core.so.5
#7  0x7f3fdc5e6d1e in QClipboard::changed(QClipboard::Mode) () from
/usr/lib/libQt5Gui.so.5
#8  0x7f3fcd7b9629 in ?? () from /usr/lib/libQt5XcbQpa.so.5
#9  0x7f3fcd7c2048 in QXcbConnection::handleXcbEvent(xcb_generic_event_t*)
() from /usr/lib/libQt5XcbQpa.so.5
#10 0x7f3fcd7c2b73 in QXcbConnection::processXcbEvents() () from
/usr/lib/libQt5XcbQpa.so.5
#11 0x7f3fdbf5a1e1 in QObject::event(QEvent*) () from
/usr/lib/libQt5Core.so.5
#12 0x7f3fdca2e9ac in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() from /usr/lib/libQt5Widgets.so.5
#13 0x7f3fdca33e86 in QApplication::notify(QObject*, QEvent*) () from
/usr/lib/libQt5Widgets.so.5
#14 0x7f3fdbf2abab in QCoreApplication::notifyInternal(QObject*, QEvent*)
() from /usr/lib/libQt5Core.so.5
#15 0x7f3fdbf2cfa6 in QCoreApplicationPrivate::sendPostedEvents(QObject*,
int, QThreadData*) () from /usr/lib/libQt5Core.so.5
#16 0x7f3fdbf81143 in ?? () from /usr/lib/libQt5Core.so.5
#17 0x7f3fd85d7dc7 in g_main_context_dispatch () from
/usr/lib/libglib-2.0.so.0
#18 0x7f3fd85d8020 in ?? () from /usr/lib/libglib-2.0.so.0
#19 0x7f3fd85d80cc in g_main_context_iteration () from
/usr/lib/libglib-2.0.so.0
#20 0x7f3fdbf8154f in
QEventDispatcherGlib::processEvents(QFlags) ()
from /usr/lib/libQt5Core.so.5
#21 0x7f3fdbf2857a in
QEventLoop::exec(QFlags) () from
/usr/lib/libQt5Core.so.5

[plasmashell] [Bug 359066] Plasma workspace freezes for 10 seconds upon selecting text in an untrusted X11 session (e.g. ssh -X)

[Rob via KDE Bugzilla]

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

--- Comment #4 from Rob  ---
I digged up an old debug build of Qt (5.5.1) and got the following. It seems to
get stuck for too long in QXcbClipboard::waitForClipboardEvent.

Thread 1 (Thread 0x7f714e57d800 (LWP 27821)):
#0  0x7f7148264e23 in select () from /usr/lib/libc.so.6
#1  0x7f7139800b90 in QXcbClipboard::waitForClipboardEvent
(this=this@entry=0xdd5f50, win=win@entry=33554495, type=type@entry=31,
timeout=timeout@entry=5000, checkManager=checkManager@entry=false) at
qxcbclipboard.cpp:932
#2  0x7f71398011af in QXcbClipboard::getSelection (this=0xdd5f50,
selection=1, target=341, property=346, time=673078026, time@entry=0) at
qxcbclipboard.cpp:1020
#3  0x7f7139802cb0 in QXcbClipboard::getDataInFormat (fmtAtom=, modeAtom=, this=) at qxcbclipboard.cpp:1005
#4  QXcbClipboardMime::formats_sys (this=0x36126d0) at qxcbclipboard.cpp:97
#5  0x7f71490b2fd9 in QInternalMimeData::formats (this=) at
kernel/qdnd.cpp:207
#6  0x7f708c33a700 in ?? () from
/usr/lib/qt/plugins/plasma/dataengine/plasma_engine_clipboard.so
#7  0x7f7148b73fb7 in QtPrivate::QSlotObjectBase::call (a=0x7fff1721bac0,
r=0x376b520, this=) at
../../include/QtCore/../../src/corelib/kernel/qobject_impl.h:124
#8  QMetaObject::activate (sender=0x31f9540, signalOffset=,
local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7fff1721bac0)
at kernel/qobject.cpp:3698
#9  0x7f7148b74927 in QMetaObject::activate (sender=,
m=m@entry=0x7f71496eb400 ,
local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7fff1721bac0)
at kernel/qobject.cpp:3578
#10 0x7f7149420bee in QClipboard::changed (this=,
_t1=QClipboard::Selection) at .moc/moc_qclipboard.cpp:158
#11 0x7f7149098383 in QPlatformClipboard::emitChanged
(this=this@entry=0xdd5f50, mode=mode@entry=QClipboard::Selection) at
kernel/qplatformclipboard.cpp:119
#12 0x7f71398013d9 in QXcbClipboard::handleXFixesSelectionRequest
(this=0xdd5f50, event=event@entry=0x7f7130004aa0) at qxcbclipboard.cpp:754
#13 0x7f7139807f58 in QXcbConnection::handleXcbEvent
(this=this@entry=0xdb4860, event=event@entry=0x7f7130004aa0) at
qxcbconnection.cpp:1157
#14 0x7f7139808bd3 in QXcbConnection::processXcbEvents (this=0xdb4860) at
qxcbconnection.cpp:1527
#15 0x7f7148b74ff1 in QObject::event (this=0xdb4860, e=) at
kernel/qobject.cpp:1239
#16 0x7f7149d0d01c in QApplicationPrivate::notify_helper
(this=this@entry=0xdab410, receiver=receiver@entry=0xdb4860,
e=e@entry=0x7f7130004320) at kernel/qapplication.cpp:3716
#17 0x7f7149d124f6 in QApplication::notify (this=0x7fff1721c2d0,
receiver=0xdb4860, e=0x7f7130004320) at kernel/qapplication.cpp:3499
#18 0x7f7148b459ab in QCoreApplication::notifyInternal
(this=0x7fff1721c2d0, receiver=0xdb4860, event=event@entry=0x7f7130004320) at
kernel/qcoreapplication.cpp:965
#19 0x7f7148b47da6 in QCoreApplication::sendEvent (event=0x7f7130004320,
receiver=) at
../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:224
#20 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0,
event_type=event_type@entry=0, data=0xda15d0) at
kernel/qcoreapplication.cpp:1593
#21 0x7f7148b48288 in QCoreApplication::sendPostedEvents
(receiver=receiver@entry=0x0, event_type=event_type@entry=0) at
kernel/qcoreapplication.cpp:1451
#22 0x7f7148b9bf43 in postEventSourceDispatch (s=0xde00b0) at
kernel/qeventdispatcher_glib.cpp:271
#23 0x7f7144957dc7 in g_main_context_dispatch () from
/usr/lib/libglib-2.0.so.0
#24 0x7f7144958020 in ?? () from /usr/lib/libglib-2.0.so.0
#25 0x7f71449580cc in g_main_context_iteration () from
/usr/lib/libglib-2.0.so.0
#26 0x7f7148b9c34f in QEventDispatcherGlib::processEvents (this=0xe02720,
flags=...) at kernel/qeventdispatcher_glib.cpp:418
#27 0x7f7148b4337a in QEventLoop::exec (this=this@entry=0x7fff1721c170,
flags=..., flags@entry=...) at kernel/qeventloop.cpp:204
#28 0x7f7148b4b33c in QCoreApplication::exec () at
kernel/qcoreapplication.cpp:1229
#29 0x00431304 in main ()

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

[plasmashell] [Bug 359066] Plasma workspace freezes for 10 seconds upon selecting text in an untrusted X11 session (e.g. ssh -X)

[Rob via KDE Bugzilla]

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

--- Comment #2 from Rob  ---
I found this bug while selecting text, but the same happens when I use Ctrl+C
to copy to the clipboard.

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