Dual monitors (1080p on HDMI-0 above, 1440x900 on VGA-0 below) running Free/Open AMD drivers. 9 times out of 10, the screen locker will have either killed kwin_x11 while running, or made it die promptly when the screen is unlocked. Reproducible: Always Steps to Reproduce: 1. install latest arch packages for KDE Frameworks and Plasma 5. 2. install free AMD drivers (because Catalyst makes baby $(deity) cry). 3. start up session, and configure screen locker to begin at a specific time 4. let screen be locked for approximately 1 hour. 5. say the magic words "Zim Zala Bim Bamba Zala Do Zala Dim", and unlock screen. 6. marvel at your beautiful plasma desktop, because you can't do anything with it, or even see the applications that were open before locking. Actual Results: kwin_x11 dies a horrible death, and the error window (allowing one to restart kwin_x11) is minimized until a) plasma5 is nice enough to let you run an application or (more likely) b) you log into tty2 and do a "DISPLAY=:0 kwin_x11 &" to make life better again. Expected Results: screen unlocks, kde session works, and at the very least, I can move around windows. Arch Linux (pacman -Syu performed this morning) Athlon II X2 12GB RAM Dual Monitors AMD Radeon HD 4200 with free drivers Happy to provide backtraces/debugging, just let me know what I should be logging.
please provide the backtrace, otherwise we cannot even look at the issue.
.
This bug is happening here. I'm also using dual monitors setup, with nvidia (352.09), though. kwin_x11 crashes while the screen is locked. I rebuilt the Archlinux package (kwin 5.3.1-1) with debug symbols, so I could provide the backtrace. The crash happened yesterday, but drkonqi did not show up - Any other suggestion to obtain this bt? Tks.
$ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope # to be able to gdb attach # login to vt2 (ctrl+alt+2), alternatively/better! login via ssh $ gdb --pid `pidof kwin_x11` 2>&1 | tee kwin.gdb # wait until gdb loaded symbols > continue # move back to vt1, in case # cause the crash # move back to vt2, in case > bt # hit enter until you're at the end of the backtrace > detach > quit # maybe restart kwin $ DISPLAY=:0 kwin_x11 & # logout $ exit --- if "bt" doesn't work, that means kwin didn't acutally crash (thus you got no DrKonqi)
(In reply to Thomas Lübking from comment #4) Thanks, Thomas. The problem is that I did not find yet a deterministic way to reproduce the issue - It just happens sometimes when I go to grab a coffee. But I'll follow the steps, attach gdb and wait for the bug. > if "bt" doesn't work, that means kwin didn't acutally crash (thus you got no > DrKonqi) Yeah, this is something I want to confirm. Yesterday, I ran the System Activity and saw that there were two kwin_x11 processes - considering their PIDs, one should be the kwin_x11 I executed manually with --replace. The other one, marked as Stopped, maybe was the kwin that 'crashed' while the lockscreen was active. But I want to double check this next time.
(In reply to Anselmo L. S. Melo (anselmolsm) from comment #5) > other one, marked as Stopped, maybe was the kwin that 'crashed' while the That would explain why DrKonqi didn't show up - and smells like trouble :-\
Created attachment 93078 [details] bt for kwin_x11 crash I obtained a bt right now, but I didn't analyze it yet. Perhaps I should add more debug symbols (Qt, for example).
backtrace looks good, though I have no idea what's going on.
looks like bug #346024 ("sddm not shown" can be taken as screen supposed to be locked) resp. bug #348873 (locking explicitly noted) Also Anselmo is (unlike the OP!) on nvidia, ie. VBO is transferred between VRAM and RAM on various occasions @Anselmo Did you also (except of course when gdb from VT1) switch the VT or suspend to ram or change the screen layout when encoutering this? ----------- #0 0x00007fcbcf95e89d in nanosleep () from /usr/lib/libc.so.6 #1 0x00007fcbcf95e734 in sleep () from /usr/lib/libc.so.6 #2 0x00007fcbcc19af5a in ?? () from /usr/lib/libKF5Crash.so.5 #3 0x00007fcbcc19b436 in KCrash::defaultCrashHandler(int) () from /usr/lib/libKF5Crash.so.5 #4 <signal handler called> #5 0x00007fcbcf9370c9 in __memcpy_sse2_unaligned () from /usr/lib/libc.so.6 #6 0x00007fcbc899c0c6 in KWin::GLVertexBuffer::setData (this=this@entry=0xe891c0, vertexCount=24, dim=dim@entry=2, vertices=0x199e758, texcoords=texcoords@entry=0x0) at /home/anselmo/arch/abs/kwin/src/kwin-5.3.1/libkwineffects/kwinglutils.cpp:2242 #7 0x00007fcbcf54432b in KWin::SceneOpenGL2::doPaintBackground (this=<optimized out>, vertices=...) at /home/anselmo/arch/abs/kwin/src/kwin-5.3.1/scene_opengl.cpp:1049 #8 0x00007fcbcf548f95 in KWin::SceneOpenGL::paintBackground (this=this@entry=0xeecd80, region=...) at /home/anselmo/arch/abs/kwin/src/kwin-5.3.1/scene_opengl.cpp:742 #9 0x00007fcbcf532fb6 in KWin::Scene::paintSimpleScreen (this=this@entry=0xeecd80, orig_mask=orig_mask@entry=8, region=...) at /home/anselmo/arch/abs/kwin/src/kwin-5.3.1/scene.cpp:371 #10 0x00007fcbcf543af3 in KWin::SceneOpenGL2::paintSimpleScreen (this=this@entry=0xeecd80, mask=mask@entry=8, region=...) at /home/anselmo/arch/abs/kwin/src/kwin-5.3.1/scene_opengl.cpp:1015 #11 0x00007fcbcf52ddd4 in KWin::Scene::finalPaintScreen (this=0xeecd80, mask=mask@entry=8, region=..., data=...) at /home/anselmo/arch/abs/kwin/src/kwin-5.3.1/scene.cpp:201 #12 0x00007fcbcf568e1f in KWin::EffectsHandlerImpl::paintScreen (this=0x13e2640, mask=mask@entry=8, region=..., data=...) at /home/anselmo/arch/abs/kwin/src/kwin-5.3.1/effects.cpp:397 #13 0x00007fcbccd41d0f in KWin::Effect::paintScreen (this=this@entry=0x108f8e0, mask=mask@entry=8, region=..., data=...) at /home/anselmo/arch/abs/kwin/src/kwin-5.3.1/libkwineffects/kwineffects.cpp:535 #14 0x00007fcbcf568dcb in KWin::EffectsHandlerImpl::paintScreen (this=0x13e2640, mask=mask@entry=8, region=..., data=...) at /home/anselmo/arch/abs/kwin/src/kwin-5.3.1/effects.cpp:394 #15 0x00007fcbccd41d0f in KWin::Effect::paintScreen (this=this@entry=0x1091e60, mask=mask@entry=8, region=..., data=...) at /home/anselmo/arch/abs/kwin/src/kwin-5.3.1/libkwineffects/kwineffects.cpp:535 #16 0x00007fcbcf568dcb in KWin::EffectsHandlerImpl::paintScreen (this=0x13e2640, mask=8, region=..., data=...) at /home/anselmo/arch/abs/kwin/src/kwin-5.3.1/effects.cpp:394 #17 0x00007fcbcf52d9ba in KWin::Scene::paintScreen (this=this@entry=0xeecd80, mask=mask@entry=0x7ffebad7017c, damage=..., repaint=..., updateRegion=updateRegion@entry=0x7ffebad70190, validRegion=validRegion@entry=0x7ffebad701a0) at /home/anselmo/arch/abs/kwin/src/kwin-5.3.1/scene.cpp:151 #18 0x00007fcbcf549ad1 in KWin::SceneOpenGL::paint (this=0xeecd80, damage=..., toplevels=...) at /home/anselmo/arch/abs/kwin/src/kwin-5.3.1/scene_opengl.cpp:661 #19 0x00007fcbcf5257b3 in KWin::Compositor::performCompositing (this=0xe44ae0) at /home/anselmo/arch/abs/kwin/src/kwin-5.3.1/composite.cpp:701 #20 0x00007fcbcd7bba93 in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5 #21 0x00007fcbce44c62c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #22 0x00007fcbce451d10 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #23 0x00007fcbcd78a57b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5 #24 0x00007fcbcd7e0b1d in QTimerInfoList::activateTimers() () from /usr/lib/libQt5Core.so.5 #25 0x00007fcbcd7df336 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #26 0x00007fcbb52ea2dd in ?? () from /usr/lib/qt/plugins/platforms/libqxcb.so #27 0x00007fcbcd787ffa in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #28 0x00007fcbcd78fa4c in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5 #29 0x00007fcbcfc4e423 in kdemain (argc=1, argv=0x7ffebad70958) at /home/anselmo/arch/abs/kwin/src/kwin-5.3.1/main_x11.cpp:300 #30 0x00007fcbcf8c7790 in __libc_start_main () from /usr/lib/libc.so.6 #31 0x00000000004007e9 in _start ()
(In reply to Thomas Lübking from comment #9) > @Anselmo > Did you also (except of course when gdb from VT1) switch the VT or suspend > to ram or change the screen layout when encoutering this? Thomas, Yes, I switched from VT1 to VT2, then back to VT1 before unlocking the screen.
That's bug #348873 and will "somehow" be related to bug #344326 Jason's original bug however was on the radeon driver, it's not sure nor likely that it's related.
(In reply to Thomas Lübking from comment #11) > That's bug #348873 and will "somehow" be related to bug #344326 > > Jason's original bug however was on the radeon driver, it's not sure nor > likely that it's related. OK. I'll follow #344326 then. Thanks.
Unfortunately we still don't have a back trace for the original reported issue. The backtrace we have is a specific situation on NVIDIA which is probably not the cause for this problem. Without the backtrace we cannot further investigate the issue.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!