Created attachment 169422 [details] Support info SUMMARY For a couple of years now I have been having continual intermittent crashes of KWin, with all stack traces revolving around KWin::EffectWindow or similar. I generally see this a few times a week, but sometimes more or less frequently. This has occurred in both X11 and Wayland, with the crash generally being more disruptive now under Wayland, since all apps are lost. Whenever I try to report this via DrKonqi it tells me the crash info isn't useful, even after installing debug info, so this could be getting underreported. I don't think I have anything particularly unusual in terms of config. Lots of backtraces attached along with sysinfo. Anything else you need let me know. STEPS TO REPRODUCE Not deterministcally reproducible every time, but most often recently the crash occurs as the mouse is moved over an application tab on the Task Manager. OBSERVED RESULT KWin segmentation fault, all applications closed, black screen then return to empty desktop EXPECTED RESULT No crash SOFTWARE/OS VERSIONS This has been ongoing for a long time with no resolution, for example see https://bugs.kde.org/show_bug.cgi?id=437925. Still occured in Fedora 38 and 39, with their relevant versions of KDE. Linux/KDE Plasma: Fedora 40 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 ADDITIONAL INFORMATION Using Wayland, but same crash happened on X11 AMD graphics
Created attachment 169423 [details] Backtrace 1
Created attachment 169424 [details] Backtrace 2
Created attachment 169425 [details] Backtrace 3
Created attachment 169426 [details] Backtrace 4
Created attachment 169427 [details] Backtrace 5
Created attachment 169428 [details] Backtrace 6
Created attachment 170089 [details] Backtrace 7
Created attachment 170420 [details] Backtrace 8
I looked into this crash for a bit but I don't understand how kwin could crash (iiuc the EffectWindow is likely deleted). If you disable window animation effects and just keep blur and background contrast effects enabled, is there still this crash?
(In reply to Vlad Zahorodnii from comment #9) > I looked into this crash for a bit but I don't understand how kwin could > crash (iiuc the EffectWindow is likely deleted). If you disable window > animation effects and just keep blur and background contrast effects > enabled, is there still this crash? I've tried toggling various window effects, but perhaps not tried turning off just the animation related ones. Given the crash occurs only very intermittently, it's been hard to know what might work and what's just luck. In general, the 'this' pointer of EffectWindow when shown in the backtraces looks like a reasonable value for an address, so it seems more likely that this might be a use of the pointer beyond its lifetime, rather than a use of an invalid pointer before the EffectWindow is created (we'd see nullptr anyway I believe, as it comes from a unique_ptr.get() in window->effectWindow()). I had a bit of a dig through the kwin code though and it seems like the plugins should drop all internal uses of an effect window ptr when they receive the EffectsHandler::windowDeleted signal. This signal comes only from a connection to Workspace::deletedRemoved, which itself is only emitted in one place: the final unref of a window that takes it to 0, which then immediately deletes the window (and the effect window with it). There doesn't seem to be any clear mechanism for this to get out of sync (i.e window deleted but EffectsHandler::windowDeleted not called), so my vague guess is perhaps there is an unbalanced ref/unref on a window somewhere, such the window gets deleted even whilst other classes think they've sufficiently ref'd it to prevent deletion. In particular, the animation related effects appear to rely more heavily on the ref/unref system, which I guess is why you're asking? I've tried creating/destroying windows in a tight loop and triggering various effects whilst doing so, but cannot recreate the crash, so whatever is causing this seems to be extremely niche. I'll try disabling animation related effects, but determining the lack of a crash is going to be a slow process
Created attachment 170523 [details] Backtrace 9
This abruptly stopped happening at some point in perhaps July and I haven't seen it again since