[plasmashell] [Bug 370924] New: Brightness slider slowly "moving back" after dragging the slider thumb.
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&a=blob&h=cd92a28ca64af518409adbad9d5fb3eeebd59a1c&hb=e7a07a154006a270149d78eeb2abd114b5ab816a&f=applets%2Fbatterymonitor%2Fpackage%2Fcontents%2Fui%2FPopupDialog.qml#l42
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 370003] New: Performance issues (laggy animations, stuttering keyboard input handling, severe frame drops in videos) after using plasmashell for a few days
https://bugs.kde.org/show_bug.cgi?id=370003 Bug ID: 370003 Summary: Performance issues (laggy animations, stuttering keyboard input handling, severe frame drops in videos) after using plasmashell for a few days Product: plasmashell Version: 5.7.5 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 101421 --> https://bugs.kde.org/attachment.cgi?id=101421&action=edit perf record -e cpu-clock -p `pidof plasmashell` -o perf2.data # switch between desktops a couple of times and ^C For many months I have experienced performance issues: - Obvious animation lags, e.g. switching between desktops, or hiding/restoring windows - Keyboard input handling seems to stutter, e.g. typing in the terminal or browser is not smooth: If I hold a key pressed, instead of showing a steady stream of characters, the input seems to stutter. - Videos are shown with multiple framedrops every few seconds, e.g. in VLC or in YouTube/Facebook videos in Chromium. Although I don't know how to reproduce the issue, it is not a question of whether the performance issues occur, but when (maybe after a few hours of use?). The issue is really caused by plasmashell, if I stop plasmashell the performance issues disappear, when I resume plasmashell the issues return: $ pkill -SIGSTOP plasmashell # perf issues gone, and plasmashell is obviously unusable (frozen/stopped). $ pkill -SIGCONT plasmashell # perf issues back The work-around to restart plasmashell, but doing so reorders the task items so it is not free of side effects. $ kquitapp5 plasmashell && kstart5 plasmashell --- ADDITIONAL INFORMATION After about a week of usage (with a few suspend/resume in between, some web browsing and using the terminal), I saw the issue again. I used "ps -o pcpu -C plasmashell" to get the CPU usage and saw the reported CPU drop from 28.8 to 2.2 after restarting plasmashell. After taking two more measures after an hour and another few hours the numbers slowly climbed to 2.5, then 3.8%. Then I recorded the CPU usage using perf while switching between desktops (5 times). The result is shown below (and attached). It seems that something in plasmashell is holding locks excessively often. And also the time spent by qstrcmp is a bit suspicious. $ perf record -e cpu-clock -p `pidof plasmashell` -o perf2.data $ perf report -i perf2.data Samples: 19K of event 'cpu-clock:u', Event count (approx.): 492650 Overhead Command Shared Object Symbol 16.53% plasmashell libpthread-2.24.so [.] __lll_lock_elision 7.91% plasmashell libpthread-2.24.so [.] __lll_unlock_elision 7.74% plasmashell libQt5Core.so.5.7.0 [.] qstrcmp 5.80% QXcbEventReader libpthread-2.24.so [.] __lll_lock_elision 5.31% QXcbEventReader libc-2.24.so[.] malloc 3.96% plasmashell libc-2.24.so[.] _int_free 3.32% plasmashell libQt5Core.so.5.7.0 [.] QAbstractEventDispatcher::filterNativeEvent 3.27% plasmashell libc-2.24.so[.] malloc 2.77% QXcbEventReader libc-2.24.so[.] _int_malloc 2.53% plasmashell libc-2.24.so[.] malloc_consolidate 2.51% QXcbEventReader libc-2.24.so[.] __memmove_avx_unaligned_erms 2.34% plasmashell libc-2.24.so[.] _int_malloc 1.75% plasmashell libQt5Core.so.5.7.0 [.] QMutex::lock 1.38% plasmashell libQt5Core.so.5.7.0 [.] QMutex::unlock 1.33% plasmashell libQt5XcbQpa.so.5.7.0 [.] QXcbConnection::processXcbEvents 1.32% QXcbEventReader libpthread-2.24.so [.] __lll_unlock_elision 1.26% QXcbEventReader libpthread-2.24.so [.] pthread_cond_signal@@GLIBC_2.3.2 -- 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
https://bugs.kde.org/show_bug.cgi?id=370003 --- Comment #1 from Rob --- Created attachment 101422 --> https://bugs.kde.org/attachment.cgi?id=101422&action=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.
[plasmashell] [Bug 370003] Performance issues (laggy animations, stuttering keyboard input handling, severe frame drops in videos) after using plasmashell for a few days
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.
[kstars] [Bug 361646] KStars hogs CPU until unusable
https://bugs.kde.org/show_bug.cgi?id=361646 --- Comment #6 from Rob --- Created attachment 98551 --> https://bugs.kde.org/attachment.cgi?id=98551&action=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
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
https://bugs.kde.org/show_bug.cgi?id=361646 --- Comment #8 from Rob --- Created attachment 98552 --> https://bugs.kde.org/attachment.cgi?id=98552&action=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
https://bugs.kde.org/show_bug.cgi?id=361646 --- Comment #9 from Rob --- Created attachment 98553 --> https://bugs.kde.org/attachment.cgi?id=98553&action=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
https://bugs.kde.org/show_bug.cgi?id=361646 --- Comment #10 from Rob --- Created attachment 98554 --> https://bugs.kde.org/attachment.cgi?id=98554&action=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
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
https://bugs.kde.org/show_bug.cgi?id=361646 --- Comment #12 from Rob --- Created attachment 98568 --> https://bugs.kde.org/attachment.cgi?id=98568&action=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
https://bugs.kde.org/show_bug.cgi?id=361646 --- Comment #13 from Rob --- Created attachment 98674 --> https://bugs.kde.org/attachment.cgi?id=98674&action=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
https://bugs.kde.org/show_bug.cgi?id=361646 --- Comment #14 from Rob --- Created attachment 98675 --> https://bugs.kde.org/attachment.cgi?id=98675&action=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
https://bugs.kde.org/show_bug.cgi?id=361646 --- Comment #15 from Rob --- Created attachment 98676 --> https://bugs.kde.org/attachment.cgi?id=98676&action=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
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
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
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
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
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 362822] New: KStars receives segfault in libqcxb when I close my laptop lid
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 362822] KStars receives segfault in libqcxb when I close my laptop lid
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 361646] New: KStars hogs CPU until unusable
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.
[kstars] [Bug 361646] KStars hogs CPU until unusable
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] KStars hogs CPU until unusable
https://bugs.kde.org/show_bug.cgi?id=361646 --- Comment #1 from Rob --- One more thing: before running on Xubuntu I had tried KStars on Ubuntu and the situation was the same. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 361646] KStars hogs CPU until unusable
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
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.
[plasmashell] [Bug 359066] New: Plasma workspace freezes for 10 seconds upon selecting text in an untrusted X11 session (e.g. ssh -X)
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&action=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
[plasmashell] [Bug 359066] Plasma workspace freezes for 10 seconds upon selecting text in an untrusted X11 session (e.g. ssh -X)
https://bugs.kde.org/show_bug.cgi?id=359066 --- Comment #1 from Rob --- Created attachment 97047 --> https://bugs.kde.org/attachment.cgi?id=97047&action=edit Full output of sudo gdb -q -p `pidof plasmashell` -batch -ex 'thread apply all bt' -- 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)
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.
[plasmashell] [Bug 359066] Plasma workspace freezes for 10 seconds upon selecting text in an untrusted X11 session (e.g. ssh -X)
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.
[kmid] [Bug 359424] New: KMid crashes on opening some MIDI files
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.
