SUMMARY KWin crashes when (un)plugging HDMI cable while plasmashell was restarting due to it crashing. My screen setup is either laptop screen or external screen, so when I plug in HDMI, my laptop screen turns off(!) and the HDMI screen is used, so it seems when plasmashell restarts in the meantime, it can happen that KWin wants to manage that client in that split second it doesn't have any (or garbage) outputs(?) STEPS TO REPRODUCE 1. Plug in HDMI cable 2. When prompted by KScreen set "external only" (or manually change it so that whenever you plug in the HDMI cable, laptop screen turns off and HDMI is only used) 3. Plug cable out or in a couple of times, maybe send SIGABRT to plasmashell manually in the meantime if it doesn't crash OBSERVED RESULT KWin crashes EXPECTED RESULT KWin does not crash SOFTWARE/OS VERSIONS Linux/KDE Plasma: git master as of 2021-01-07 ADDITIONAL INFORMATION #3 0x00007fdff0e866d2 in KWin::Toplevel::isOnOutput(KWin::AbstractOutput*) const (this=this@entry=0x55d4f286eb50, output=0x7fdfe40093b0) at ./src/toplevel.cpp:423 #4 0x00007fdff0eb7d41 in KWin::Workspace::activeOutput() const (this=0x55d4f1974e80) at ./src/workspace.cpp:2420 #5 0x00007fdff0ee216f in KWin::X11Client::manage(unsigned int, bool) (this=this@entry=0x55d4f2bad4c0, w=w@entry=62914624, isMapped=isMapped@entry=false) at ./src/workspace.h:811 #6 0x00007fdff0ec319f in KWin::Workspace::createClient(unsigned int, bool) (this=this@entry=0x55d4f1974e80, w=62914624, is_mapped=is_mapped@entry=false) at ./src/workspace.cpp:654 #7 0x00007fdff0dc8d9d in KWin::Workspace::workspaceEvent(xcb_generic_event_t*) (this=0x55d4f1974e80, e=e@entry=0x7fdfe400d590) at ./src/events.cpp:223 #8 0x00007fdff0e07094 in KWin::Application::dispatchEvent(xcb_generic_event_t*) (this=<optimized out>, event=0x7fdfe400d590) at ./src/workspace.h:811
Either Workspace::active_client or Workspace::m_activeOutput (or both) is garbage. Can you reproduce the issue reliably?
also, is this x11 or wayland session?
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 mark the bug 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!
Created attachment 146947 [details] New crash information added by DrKonqi kwin_x11 (5.24.1) using Qt 5.15.2 - What I was doing when the application crashed: I was waking the screen from sleep. The system would switch off the two monitors after the set timeout (the system itself, kernel and all, does not sleep, just the monitors are turned off). When reawakening, the monitors are slow to react (one in particular can go back and forth a couple of times, spending a few seconds). On the first wake up, the crash happens and the panel which is usually at the bottom of the screen does not show up. This happens pretty much every first wake up in the session. If the monitors go sleeping again after a while, on waking chances are that instead the panel reappears. Usually the third wake up sees the crash again, and so forth. I may have a whole core file somewhere, if coredumpctl is nice with me. I believe this is strongly related to the original report, with which it shares the slowness of the response from the monitor hardware. This is kwin_x11. This is a new issue for me, since two weeks ago. I think the issue may have appeared either with kwin 5.23.5, or 5.23.5-r1 (that's Gentoo patch numbering, so I don't know how that translates into KDE). Definitely there with 5.24. Each time I update the whole system. -- Backtrace (Reduced): #4 0x00007efd569fee5c in KWin::Toplevel::isOnOutput (this=0x55f5c1943a10, output=0x55f5c18f7340) at /usr/src/debug/kde-plasma/kwin-5.24.1/kwin-5.24.1/src/toplevel.cpp:423 #5 0x00007efd56a2dde9 in KWin::Workspace::activeOutput (this=0x55f5c14f2190) at /usr/src/debug/kde-plasma/kwin-5.24.1/kwin-5.24.1/src/workspace.cpp:2419 #6 0x00007efd56aa9513 in KWin::TabBox::SwitcherItem::screenGeometry (this=<optimized out>) at /usr/src/debug/kde-plasma/kwin-5.24.1/kwin-5.24.1/src/tabbox/switcheritem.cpp:74 #7 0x00007efd568b7525 in KWin::TabBox::SwitcherItem::qt_static_metacall (_o=<optimized out>, _c=<optimized out>, _id=<optimized out>, _a=<optimized out>) at /usr/src/debug/kde-plasma/kwin-5.24.1/kwin-5.24.1_build/src/kwin_autogen/WF44ZIICEP/moc_switcheritem.cpp:210 #8 0x00007efd568d04c3 in KWin::TabBox::SwitcherItem::qt_metacall (this=0x55f5c1f589e0, _c=QMetaObject::ReadProperty, _id=1, _a=0x7ffe9fbdb220) at /usr/src/debug/kde-plasma/kwin-5.24.1/kwin-5.24.1_build/src/kwin_autogen/WF44ZIICEP/moc_switcheritem.cpp:273
*** Bug 450924 has been marked as a duplicate of this bug. ***
Looks like X11, and the duplicate report Bug 450924 is also X11.
*** Bug 451972 has been marked as a duplicate of this bug. ***
*** Bug 452083 has been marked as a duplicate of this bug. ***
*** Bug 450337 has been marked as a duplicate of this bug. ***
So also available if you play with dp port (in my case daisy chained screen) X11 + nvidia My last dump is attached to 450337
*** Bug 452997 has been marked as a duplicate of this bug. ***
Workspace::m_activeOutput is garbage. "Forcefully" (I cannot find it in System Settings) taking activeMouseScreen() code path in Workspace::activeOutput() seems to work so far.
*** Bug 453089 has been marked as a duplicate of this bug. ***
*** Bug 453117 has been marked as a duplicate of this bug. ***
Increasing priority due to number of duplicates.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2448
Git commit 4c3195270d6c8e1da8c3e2e3abe5aae75d5bf3c2 by Vlad Zahorodnii. Committed on 21/05/2022 at 11:03. Pushed by merge-service into branch 'Plasma/5.24'. Ensure that Toplevel::output() stays always in sync with geometry Currently, if geometry updates are blocked, the Toplevel.output property won't be updated. On the other hand, it's reasonable to use the output property instead of manually looking up the output in window management code, e.g. Workspace::clientArea(). In other words, using the Toplevel.output property is like walking on a mine field, things can blow up. You can't use Toplevel.output even if it makes perfect sense. This change ensures that Toplevel.output property is always kept in sync with the frame geometry. Unfortunately, this means that the output property no longer can be updated when the frameGeometryChanged() signal is emitted. It has to be done in moveResizeInternal() method. (cherry picked from 510a41eeb89f51843405fa0258c852ab06d05bb8) Part-of: <https://invent.kde.org/plasma/kwin/-/merge_requests/2448> M +0 -3 src/abstract_client.cpp M +1 -0 src/events.cpp M +6 -0 src/internal_client.cpp M +0 -17 src/toplevel.cpp M +2 -8 src/toplevel.h M +6 -0 src/unmanaged.cpp M +1 -0 src/unmanaged.h M +6 -0 src/waylandclient.cpp M +7 -0 src/x11client.cpp M +1 -0 src/x11client.h https://invent.kde.org/plasma/kwin/commit/4c3195270d6c8e1da8c3e2e3abe5aae75d5bf3c2
Git commit a8477c1cf7acbf3358c85e53b236150dd43b4640 by Vlad Zahorodnii, on behalf of Xaver Hugl. Committed on 21/05/2022 at 11:08. Pushed by merge-service into branch 'Plasma/5.24'. toplevel: set valid output in the constructor This makes it less easy to cause crashes and fixes some segfaults. Related: bug 452433 (cherry picked from commit e48a5c0535f01dc380449ba8481c869ff23e5558) Tested-by: Merge Service <https://invent.kde.org/plasma/kwin/-/merge_requests/2448> Part-of: <https://invent.kde.org/plasma/kwin/-/merge_requests/2448> M +2 -1 src/toplevel.cpp https://invent.kde.org/plasma/kwin/commit/a8477c1cf7acbf3358c85e53b236150dd43b4640
*** Bug 454681 has been marked as a duplicate of this bug. ***
*** Bug 455399 has been marked as a duplicate of this bug. ***