SUMMARY When there are many windows visible on the screen (maybe it's to do with the number of windows or the time it takes to render the new activity?), switching activities too quickly can cause kwin to crash. This is most observable when using activity-aware firefox, as this crash crashes all of the Firefox instances as well. Another side-effect is that all windows are placed on the default activity after the crash STEPS TO REPRODUCE 1. Set up a desktop with two activities 2. On one, open many windows with at least one non-KDE app (e.g. Signal Desktop or Firefox) 3. On another, open many windows with at least one non-KDE app (e.g. LibreOffice) NOTE: Whether the same app has windows on both activities does not appear to be relevant, but it's much harder to reproduce with only KDE apps open. 4. Spam Meta+A to quickly swap between activities OBSERVED RESULT After several switches back and forth, kwin crashes and restarts. EXPECTED RESULT kwin does not crash SOFTWARE/OS VERSIONS Operating System: Kubuntu 25.10 KDE Plasma Version: 6.3.91 KDE Frameworks Version: 6.14.0 Qt Version: 6.8.3 Kernel Version: 6.14.0-15-generic (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 7840U w/ Radeon 780M Graphics Memory: 64 GiB of RAM (60.6 GiB usable) Graphics Processor: AMD Radeon 780M ADDITIONAL INFORMATION This seems to have been introduced between 6.3.5 and 6.3.90, but it still occurs on 6.3.91. I will try to get a backtrace this weekend.
If something crashed, we need a backtrace of it so we can figure out what's going on. Can you please attach a backtrace of the crash using the `coredumpctl` command-line program, as detailed in https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl? Thanks!
How long do you have to spam Meta+A before you see a crash? I tried spamming it for about 30 seconds and didn't see anything happen.
(In reply to James J. Ramsey from comment #2) > How long do you have to spam Meta+A before you see a crash? I tried spamming > it for about 30 seconds and didn't see anything happen. With 6.4.0 it seems to be less frequent and I can only reliably reproduce with 3 monitors attached. It also seems to occur more reliably if I change display layouts a few more times.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.
I've sent in several crash reports, including one just this morning. Using activity-aware Firefox and having multiple Firefox windows open on each activity does appear to make the crashes more reliable.
Ok, the latest from kwin-wayland 6.4.4 is that I can only reproduce this: - On my laptop that has an AMD GPU - After adding or removing displays Laptops with Intel and NVIDIA graphics haven't been able to reproduce it, so it could be a bug in the AMD driver. However, whatever it is, only kwin-wayland and Firefox are affected, and I think that Firefox is crashing because it can't handle the compositor going down for a few seconds.
Marking this as resolved in 6.4.5 as I have been unable to reproduce it there. I can still cause a crash by switching out .so files that widgets use, but that's a separate issue. (I guess the question there would be what the correct behaviour is? Restart just that widget? Does it need its own process? etc.)