| Summary: | Repeated segmentation fault crashes in various KWin::EffectWindow related functions | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Adam L <new.plan4033> |
| Component: | effects-various | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | 6.0.4 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Support info
Backtrace 1 Backtrace 2 Backtrace 3 Backtrace 4 Backtrace 5 Backtrace 6 Backtrace 7 Backtrace 8 Backtrace 9 |
||
|
Description
Adam L
2024-05-13 10:26:31 UTC
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 |