Created attachment 172556 [details] Extract of crash from /var/log/messages SUMMARY Kwin crashes out of the blue on an unloaded system, seemingly unrelated to ongoing light user activity. System had copious free RAM and CPU and is airgapped, so that external causes can be precluded. Kwin was quickly restarted by systemd – so usability impact was low … Backtrace cannot be provided as DrKonqui failed to start (obviously …). STEPS TO REPRODUCE 1. not known OBSERVED RESULT Kwin crashes EXPECTED RESULT Kwin shouldn't crash SOFTWARE/OS VERSIONS Operating System: openSUSE Leap 15.6 KDE Plasma Version: 5.27.11 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.12 Kontact Version: 5.24.5 (23.08.5) Kernel Version: 6.4.0-150600.23.14-default (64-bit) Graphics Platform: X11 Processors: 8 × AMD Ryzen 5 with Radeon Vega Graphics Memory: 14.6 GiB of RAM ADDITIONAL INFORMATION KWin-Support-Infos: ========================== Version ======= KWin version: 5.27.11 Qt Version: 5.15.12 Qt compile version: 5.15.12 XCB compile version: 1.13 Operation Mode: X11 only Build Options ============= KWIN_BUILD_DECORATIONS: yes KWIN_BUILD_TABBOX: yes KWIN_BUILD_ACTIVITIES: yes HAVE_X11_XCB: yes HAVE_EPOXY_GLX: yes X11 === Vendor: The X.Org Foundation Vendor Release: 12101011 Protocol Version/Revision: 11/0 SHAPE: yes; Version: 0x11 RANDR: yes; Version: 0x14 DAMAGE: yes; Version: 0x11 Composite: yes; Version: 0x4 RENDER: yes; Version: 0xb XFIXES: yes; Version: 0x50 SYNC: yes; Version: 0x31 GLX: yes; Version: 0x0 Decoration ========== Plugin: org.kde.breeze Theme: Plugin recommends border size: None onAllDesktopsAvailable: true alphaChannelSupported: true closeOnDoubleClickOnMenu: false decorationButtonsLeft: 0, 1 decorationButtonsRight: 3, 4, 6, 5 borderSize: 2 gridUnit: 10 font: Noto Sans,11,-1,5,63,0,0,0,0,0,SemiBold smallSpacing: 2 largeSpacing: 10 Output backend ============== Name: KWin::X11StandaloneBackend Cursor ====== themeName: Oxygen 04 Red Ruby themeSize: 24 Options ======= focusPolicy: 1 xwaylandCrashPolicy: xwaylandMaxCrashCount: 3 nextFocusPrefersMouse: false clickRaise: true autoRaise: true autoRaiseInterval: 500 delayFocusInterval: 750 shadeHover: false shadeHoverInterval: 250 separateScreenFocus: false activeMouseScreen: true placement: activationDesktopPolicy: 0 focusPolicyIsReasonable: true borderSnapZone: 10 windowSnapZone: 10 centerSnapZone: 0 snapOnlyWhenOverlapping: false rollOverDesktops: true focusStealingPreventionLevel: 2 operationTitlebarDblClick: 5015 operationMaxButtonLeftClick: 5000 operationMaxButtonMiddleClick: 5015 operationMaxButtonRightClick: 5014 commandActiveTitlebar1: 0 commandActiveTitlebar2: 0 commandActiveTitlebar3: 2 commandInactiveTitlebar1: 4 commandInactiveTitlebar2: 4 commandInactiveTitlebar3: 2 commandWindow1: 7 commandWindow2: 8 commandWindow3: 8 commandWindowWheel: 28 commandAll1: 10 commandAll2: 3 commandAll3: 14 keyCmdAllModKey: 16777251 condensedTitle: false electricBorderMaximize: false electricBorderTiling: false electricBorderCornerRatio: 0.25 borderlessMaximizedWindows: false killPingTimeout: 5000 hideUtilityWindowsForInactive: true compositingMode: 1 useCompositing: true hiddenPreviews: 1 glSmoothScale: 2 glStrictBinding: true glStrictBindingFollowsDriver: true glPreferBufferSwap: 101 glPlatformInterface: 1 windowsBlockCompositing: true latencyPolicy: renderTimeEstimator: allowTearing: true Screen Edges ============ desktopSwitching: false desktopSwitchingMovingClients: false cursorPushBackDistance: 1x1 timeThreshold: 150 reActivateThreshold: 350 actionTopLeft: 0 actionTop: 0 actionTopRight: 0 actionRight: 0 actionBottomRight: 2 actionBottom: 0 actionBottomLeft: 5 actionLeft: 0 Screens ======= Active screen follows mouse: yes Number of Screens: 2 Screen 0: --------- Name: eDP-1 Enabled: 1 Geometry: 0,1080,1920x1080 Scale: 1 Refresh Rate: 60049 Adaptive Sync: incapable Screen 1: --------- Name: HDMI-1 Enabled: 1 Geometry: 1,0,1920x1080 Scale: 1 Refresh Rate: 60000 Adaptive Sync: incapable Compositing =========== Compositing is active Compositing Type: OpenGL OpenGL vendor string: Intel OpenGL renderer string: Mesa Intel(R) UHD Graphics (CML GT2) OpenGL version string: 4.6 (Compatibility Profile) Mesa 23.3.4 OpenGL platform interface: GLX OpenGL shading language version string: 4.60 Driver: Intel GPU class: Comet Lake OpenGL version: 4.6 GLSL version: 4.60 Mesa version: 23.3.4 X server version: 1.21.1 Linux kernel version: 6.4 Direct rendering: Requires strict binding: yes GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no OpenGL 2 Shaders are used Loaded Effects: --------------- colorpicker outputlocator mouseclick screenshot trackmouse zoom blur contrast kwin4_effect_sessionquit kwin4_effect_logout kwin4_effect_login kwin4_effect_windowaperture slide kwin4_effect_fullscreen kwin4_effect_squash kwin4_effect_scale kwin4_effect_fadingpopups kwin4_effect_dimscreen kwin4_effect_morphingpopups kwin4_effect_maximize kwin4_effect_frozenapp desktopgrid highlightwindow overview tileseditor windowview blendchanges startupfeedback kscreen Currently Active Effects: ------------------------- blur contrast Effect Settings: ---------------- colorpicker: outputlocator: mouseclick: color1: #008000 color2: #ff8000 color3: #0000ff lineWidth: 2 ringLife: 1000 ringSize: 30 ringCount: 3 showText: true font: Noto Sans,10,-1,5,50,0,0,0,0,0,Regular enabled: false screenshot: trackmouse: modifiers: 335544320 mousePolling: true zoom: zoomFactor: 1.2 mousePointer: 0 mouseTracking: 0 focusTrackingEnabled: false textCaretTrackingEnabled: false focusDelay: 350 moveFactor: 20 targetZoom: 1 blur: contrast: kwin4_effect_sessionquit: pluginId: kwin4_effect_sessionquit isActiveFullScreenEffect: false kwin4_effect_logout: pluginId: kwin4_effect_logout isActiveFullScreenEffect: false kwin4_effect_login: pluginId: kwin4_effect_login isActiveFullScreenEffect: false kwin4_effect_windowaperture: pluginId: kwin4_effect_windowaperture isActiveFullScreenEffect: false slide: horizontalGap: 45 verticalGap: 20 slideBackground: true kwin4_effect_fullscreen: pluginId: kwin4_effect_fullscreen isActiveFullScreenEffect: false kwin4_effect_squash: pluginId: kwin4_effect_squash isActiveFullScreenEffect: false kwin4_effect_scale: pluginId: kwin4_effect_scale isActiveFullScreenEffect: false kwin4_effect_fadingpopups: pluginId: kwin4_effect_fadingpopups isActiveFullScreenEffect: false kwin4_effect_dimscreen: pluginId: kwin4_effect_dimscreen isActiveFullScreenEffect: false kwin4_effect_morphingpopups: pluginId: kwin4_effect_morphingpopups isActiveFullScreenEffect: false kwin4_effect_maximize: pluginId: kwin4_effect_maximize isActiveFullScreenEffect: false kwin4_effect_frozenapp: pluginId: kwin4_effect_frozenapp isActiveFullScreenEffect: false desktopgrid: activeView: gridRows: 2 gridColumns: 2 animationDuration: 150 layout: 1 partialActivationFactor: 0 gestureInProgress: false showAddRemove: true desktopNameAlignment: 0 desktopLayoutMode: 0 customLayoutRows: 2 highlightwindow: overview: activeView: animationDuration: 150 layout: 1 ignoreMinimized: false blurBackground: true partialActivationFactor: 0 gestureInProgress: false searchText: tileseditor: activeView: animationDuration: 200 windowview: activeView: animationDuration: 150 layout: 1 ignoreMinimized: false mode: 0 partialActivationFactor: 0 gestureInProgress: false searchText: blendchanges: startupfeedback: type: 1 kscreen: Loaded Plugins: --------------- kwin5_plugin_krunner kwin5_plugin_nightcolor Available Plugins: ------------------ kwin5_plugin_buttonrebinds kwin5_plugin_colord kwin5_plugin_krunner kwin5_plugin_nightcolor
Please get a backtrace for the crash: https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl
(In reply to Zamundaaa from comment #1) > Please get a backtrace for the crash: > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/ > How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl I'd read that guideline – but as explained in the summary, I can't provide a coredump: DrKonqui failed to start because Kwin was gone. I do not have coredumpctl installed, as this is one of the 2 systems were I only use rock-solid, time-tested SW and normally have no need for this and no coredumps are written. The crash happened out of the blue with no obvious trigger from activity on the system. Thus it is not reproducible so far … Thus I cannot produce a backtrace ex post … I provided what is available. When DrKonqui somewhere leaves any intermediary information point me to it and I'll retrieve it.
If you can't produce a backtrace of the crash, then there's no way for us to debug it and help you, sorry. I recommend installing `coredumpctl` in the future to make life easier in situations like this.
It does not work for all those people: https://bbs.archlinux.org/viewtopic.php?id=281129 https://forum.manjaro.org/t/how-to-troubleshoot-broken-kde-plasma-window-manager/133533 https://forum.garudalinux.org/t/kwin-x11-crashing-repeatedly/25240 https://forum.manjaro.org/t/kwin-core-xcb-error-reproducible/78330 https://forums.opensuse.org/t/kde-plasma-random-crashing-tumbleweed/162569 https://github.com/FreeRDP/FreeRDP/issues/8114 WORKSFORME IMHO shows gross disrespect to all those people … All not coming here for help – wonder why? (Help is meant two-way: Reporting bugs here is both about getting help yourself as well as providing help to KDE!) My case is potentially a regression, if the original MESA change was re-introduced … See Bug 461316 and Bug 457847 … And of course there is a further bug: DrKonqi is meant to produce a backtrace – as can be seen from my provided logs. Of course it can't with kwin gone. This is a bug, as intended behavior fails. Either a DrKonqi bug – DrKonqi needs a reporting strategy if kwin is gone – or a (further) kwin bug – kwin shouldn't use DrKonqi as method to provide backtraces … (But I'm meanwhile tired of reporting bugs here: It's probably contributing to karma but definitely not to joy …)
I understand it's frustrating for your non-actionable bug report to be closed as RESOLVED WORKSFORME, but there's a solution to that: make it actionable. If you aren't able to, maybe any of those people might be able to. Bug reporting is a technical process that demands something from the bug reporter too. See https://community.kde.org/Get_Involved/Issue_Reporting#Issue_reporting_involves_responsibility. The issue with being unable to get a backtrace for KWin was solved in Plasma 6 which was released 6 months ago, but unfortunately you're still on Plasma 5, so that doesn't help either. There have been so many KWin changes since Plasma 5.27 that it's quite possible the issue is already fixed anyway. It could also have been fixed in a newer Mesa, Kernel, etc. Bug reports on old software like this one often end up in such a state; it's just the way things are. Using more up-to-date software definitely helps to make bug reports more actionable.
(In reply to Nate Graham from comment #5) > I understand it's frustrating for your non-actionable bug report to be > closed as RESOLVED WORKSFORME, This is not about frustration, but about attitude. I'm computer scientist, SW-engineer and project trouble-shooter with 40+ years experience, hunting difficult bugs since (and since 1986 in FLOSS). So, I completely understand, that – while I delivered what was available in the system – that is not much to work from. Read the following as "from professional to professional" and not as rant! I could perfectly well live with REPORTED and WAITINGFORINFO – because that would be factually correct and might later contribute to a more complete view when similar bug reports with other indicators pop up. Closing the issue is IMHO wrong both on the process level as well as in social communication. WORKSFORME as a state conveys gross impoliteness, disinterest and neglect as well as communicates a very egomaniac perspective not in concordance with the spirit of a community. It further communicates, that KDE doesn't care both about problems in crucial components like kwin (or KDE-PIM, see my the corresponding bug reports) and the problems KDE user experience (again, see my KDE-PIM bug reports). In German we have a shorter term for WORKSFORME: LMAA … I was a fervent user and advocate of KDE for a quarter of a century – with much heartache I'm migrating away from KDE-PIM, which was the main reason for still using KDE. Having worked on many ailing and failing projects professionally, I recognize many warning indicators in many KDE elements (programs, docs, foundation). What is your perception as QA manager by profession? > but there's a solution to that: make it actionable. If you aren't able to, maybe any of those people might be able to. So far the crash did not repeat – I check regularly for systemd-coredump collecting a core-dump (as OpenSUSE already has a counter-measure by having systemd restarting kwin, a repetition could go by without noticeable effects …) As you see from the links: I did research and I'm providing the information I'm able to collect. Obviously "those people" don't care, and – with the exception of my Kalarm bug reports – I have still to see any level of care of spirited bug resolution for the KDE LTS version at KDE-BUGS. > Bug reporting is a technical process that demands something from the bug > reporter too. See > https://community.kde.org/Get_Involved/ > Issue_Reporting#Issue_reporting_involves_responsibility. Where do I not follow my responsibility? > The issue with being unable to get a backtrace for KWin was solved in Plasma > 6 which was released 6 months ago, but unfortunately you're still on Plasma > 5, so that doesn't help either. There have been so many KWin changes since > Plasma 5.27 that it's quite possible the issue is already fixed anyway. It > could also have been fixed in a newer Mesa, Kernel, etc. Bug reports on old > software like this one often end up in such a state; it's just the way > things are. Using more up-to-date software definitely helps to make bug > reports more actionable. As given in the version section: I'm using OpenSUSE LEAP 15.6 which is current software which uses the current KDE LTS version. I use my systems for productive work and this precludes manually compiling or installing leading edge versions, because I need timely security patches. This is state of the art and not open for discussion. This professional stance should be embraced by KDE. What sense does a KDE LTS version make, if KDE does not consider itself bound by the promise of *Long Term Support*? If the only choice is "bleeding edge with continuous nasty surprises" vs. "live 2 years with bugs till repaired versions trickle downstream into well-maintained distributions", my choice is clearly the 3rd option: Switch the desktop and the tool-set. That definitely WORKSFORME and RESOLVES my problems.