[Spectacle] [Bug 374009] Spectacle keeps hanging my system
https://bugs.kde.org/show_bug.cgi?id=374009 Jonathan Ringstad <jwrings...@gmail.com> changed: What|Removed |Added CC||jwrings...@gmail.com --- Comment #9 from Jonathan Ringstad <jwrings...@gmail.com> --- I can confirm that spectacle hangs my system, on manjaro, bumblebee (proprietary nvidia + mesa intel) with kernel 4.4.70, xorg 1.19.3 and spectacle 17.04.1. Everything becomes unresponsive, even switching to a VT becomes impossible. The mouse still moves, about once every 5-15 seconds. Clicking, dragging, pressing escape or enter does not do anything (I tried all of those + waited a couple of minutes for a reaction) Using anything other than rectangle select does not hang the system, and even rectangle selection works without crashing the system *sometimes*, but I did not notice any obvious pattern. Here are the relevant-looking entries from the journalctl log: Jun 10 23:16:29 vega kdeinit5[896]: D-Bus call: "org.kde.Spectacle" : "/" : "StartAgent" : () Jun 10 23:16:29 vega dbus-daemon[859]: Activating service name='org.kde.Spectacle' Jun 10 23:16:29 vega dbus-daemon[859]: Successfully activated service 'org.kde.Spectacle' Jun 10 23:16:29 vega spectacle[8168]: WARNING: Cannot find style "org.kde.desktop" - fallback: "/usr/lib/qt/qml/QtQuick/Controls/Styles/Desktop" Jun 10 23:16:29 vega spectacle[8168]: qrc:/JobDialog.qml:67: TypeError: Cannot read property 'Layout' of null Jun 10 23:16:29 vega spectacle[8168]: qrc:/JobDialog.qml:66: TypeError: Cannot read property 'Layout' of null Jun 10 23:16:33 vega kwin_x11[945]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 57866, resource id: 33554646, major code: 10 (UnmapWindow), minor code: 0 Jun 10 23:16:33 vega kwin_x11[945]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 57871, resource id: 33554646, major code: 4 (DestroyWindow), minor code: 0 Hope that helps, and hope this bug can be resolved quickly! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 347620] Performance degradation and UI glitchyness when using multiple views across multiple monitors
https://bugs.kde.org/show_bug.cgi?id=347620 --- Comment #4 from Jonathan Ringstad <jwrings...@gmail.com> --- Just tested with 3.0. It seems that the situation is better, but it's hard to test, as krita constantly crashes in multi-window/multi-view mode. Creating a document, creating a new window, then in that new window switching to a view of the created document, then trying to paint in both windows alternatingly makes the UI block up. As the UI blocks up, it pops open a message "Group not editable". With the mouse it does work (sorta?) and the performance seems fine then. With the tablet, the UI locks up quickly, and then trying to close the document makes the entire UI hang completely or even segfault. I'm still observing the following things, however (which of these are bugs, you'll have to make a decision on, I suppose -- but some of them are rather unexpected, like the layer switching): - when switching between windows to draw in, the preset changes (is it supposed to be that way?) - when switching between windows to draw in, even though the preset changes, the outline of the preset remains the old one sometimes, so that you end up painting with a different present than what your brush outline would suggest you are using. - the tool selected also changes (e.g. line-tool in the first window vs. brush in the other) - blending mode also changes - different layers can be selected in different windows - creating a new layer in one window breaks painting in the other, until one selects a valid layer in the other window -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 343803] Konsole keeps running in background after closing window with nvidia drivers
https://bugs.kde.org/show_bug.cgi?id=343803 --- Comment #41 from Jonathan Ringstad <jwrings...@gmail.com> --- I had a look and found a bit of additional information: - The hang occurs when the libc exit handler cleans up the shared libraries of the program, so when the process starts to hang, no actual konsole code is running anymore. So that seems to make it very unlikely that the fault is with konsole - the hang occurs inside _nv014tls in /usr/lib/libnvidia-tls.so.358.16 (nvidias thread-local storage library used by GL, GLX et al), where the function falls into an infinite loop. Injecting a debugger and forcing it to return, results in konsole exiting normally. - The libc exit handler calls /usr/lib/libGL.so.1's .fini section (I think) which calls the problematic _nv014tls from the libnvidia-tls.so. - libGL gets loaded because konsole (well, Qt, I think -- konsole does not touch GLX directly) wants to do glX* calls such as glXChooseFBConfig, glXGetFBConfigAttrib, glXGetVisualFromFBConfig. no GLX context is ever initialized or destroyed from what I can tell, however (which is a bit strange, but I think should be perfectly legal to do. All the functions that are called do not require a GLX context to be present, from what I can tell.) - Re-running the exact same sequence of GLX functions in a different process does not lead to such a hang. Traceback: http://dpaste.com/0RWSDK7 I re-ran the traceback a few thousand times without a hang. So there's probably at least one more ingredient necessary to make the hang happen. That's about as far as I got. As a workaround it might be possible to make Qt not interact with GLX (if that's possible), since it's not used anyway. It seems pretty likely to me at this point that the bug is in the nvidia client driver, but I suppose there is still a chance the bug is in Qt. I think the bug is definitely not in konsole. I didn't manage to produce a minimal test-case, unfortunately. To get there, it might be useful to check if konsole loads any other nvidia client drivers, and if yes, how it interacts with them. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 343803] Konsole keeps running in background after closing window with nvidia drivers
https://bugs.kde.org/show_bug.cgi?id=343803 --- Comment #42 from Jonathan Ringstad <jwrings...@gmail.com> --- I had a look and found a bit of additional information: - The hang occurs when the libc exit handler cleans up the shared libraries of the program, so when the process starts to hang, no actual konsole code is running anymore. So that seems to make it very unlikely that the fault is with konsole - the hang occurs inside _nv014tls in /usr/lib/libnvidia-tls.so.358.16 (nvidias thread-local storage library used by GL, GLX et al), where the function falls into an infinite loop. Injecting a debugger and forcing it to return, results in konsole exiting normally. - The libc exit handler calls /usr/lib/libGL.so.1's .fini section (I think) which calls the problematic _nv014tls from the libnvidia-tls.so. - libGL gets loaded because konsole (well, Qt, I think -- konsole does not touch GLX directly) wants to do glX* calls such as glXChooseFBConfig, glXGetFBConfigAttrib, glXGetVisualFromFBConfig. no GLX context is ever initialized or destroyed from what I can tell, however (which is a bit strange, but I think should be perfectly legal to do. All the functions that are called do not require a GLX context to be present, from what I can tell.) - Re-running the exact same sequence of GLX functions in a different process does not lead to such a hang. Traceback: http://dpaste.com/0RWSDK7 I re-ran the traceback a few thousand times without a hang. So there's probably at least one more ingredient necessary to make the hang happen. That's about as far as I got. As a workaround it might be possible to make Qt not interact with GLX (if that's possible), since it's not used anyway. It seems pretty likely to me at this point that the bug is in the nvidia client driver, but I suppose there is still a chance the bug is in Qt. I think the bug is definitely not in konsole. I didn't manage to produce a minimal test-case, unfortunately. To get there, it might be useful to check if konsole loads any other nvidia client drivers, and if yes, how it interacts with them. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 343803] Konsole keeps running in background after closing window with nvidia drivers
https://bugs.kde.org/show_bug.cgi?id=343803 --- Comment #45 from Jonathan Ringstad <jwrings...@gmail.com> --- That does indeed not fix the issue, as the issue is not with OpenGL but with GLX. The GLX calls are made all the same. You can force software rendering through mesas llvm-pipe by adjusting your library path to include the mesa libGL.so first (mesas llvm-pipe driver can pretty much co-exist with any other driver without big issues -- useful for testing), but that is a rather drastic measure and not a solution I would recommend for end-users as workaround for several reasons. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 343803] Konsole keeps running in background after closing window with nvidia drivers
https://bugs.kde.org/show_bug.cgi?id=343803 --- Comment #31 from Jonathan Ringstad <jwrings...@gmail.com> --- I believe I observed the breakpoint being triggered many times, but I'm not sure how thoroughly I actually investigated that. I can collect more data later today to (hopefully) answer the question definitely. If it does indeed just hang in the nvidia function without ever returning to konsoles code, then I would agree that that makes it a much more likely candidate for being a bug in the driver; but that's still not entirely a sure thing. I can try to make a debug-build of konsole to isolate the driver<->konsole transitioning site, but I'm not sure if I'll have time this week. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 343803] Konsole keeps running in background after closing window with nvidia drivers
https://bugs.kde.org/show_bug.cgi?id=343803 --- Comment #28 from Jonathan Ringstad <jwrings...@gmail.com> --- We really don't know anything about where the issue is. All we know is that a function from the nvidia driver is getting called repeatedly, and that's where CPU time is going. I can easily invent a dozen scenarios that would cause this type of behaviour, yet it would still be my fault (the simplest being to just call whatever driver function in an infinite loop.) Seeing how the nvidia driver is generally very solidly engineered (the most reliable of all drivers by a HUGE margin, in my experience) I see no particular reason to assume it's the drivers fault. -- You are receiving this mail because: You are watching all bug changes.
