Created attachment 150500 [details] regression.mp4 SUMMARY Firefox (v103b5) and VLC (v3.0.17.4) both stop updating the window contents after being used for a while. Same happens on the panel. STEPS TO REPRODUCE 1. Normally browse the web and do other things 2. Firefox freezes, and the window content is only updated after changing the window size OBSERVED RESULT Freeze EXPECTED RESULT No freeze SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20220705 KDE Plasma Version: 5.25.80 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 Kernel Version: 5.18.6-1-default (64-bit) Graphics Platform: X11 Processors: 8 × AMD Ryzen 7 4700U with Radeon Graphics Memory: 15.0 GiB of RAM Graphics Processor: AMD RENOIR Manufacturer: HP Product Name: HP ZHAN 66 Pro A 14 G3 ADDITIONAL INFORMATION It should be a regression introduced in the recent one month.
Same bug here, it happens with all apps (x11, AMD), Started on 5.25.
I'm in the same boat. I'm almost certain it started on 5.25 KDE Neon 5.25 User Edition Linux 5.15.0-41-generic I've tried on Intel and NVidia graphics - same effect. It pretty often (a couple of times a day) happens in Firefox and Thunderbolt. Google Chrome also behaves weirdly. App restart helps till the next freeze. A window resize also refreshes content.
I've been able to reproduce what I *think* is the same issue when I maximize VLC or Firefox on X11. Only those two apps, and only on X11. A window resize refreshes the content, as others have mentioned. Can others reproduce this?
(In reply to Nate Graham from comment #3) > I've been able to reproduce what I *think* is the same issue when I maximize > VLC or Firefox on X11. Only those two apps, and only on X11. A window resize > refreshes the content, as others have mentioned. Can others reproduce this? As I mentioned in bug 431446, this also freezes Plasma for me, and all apps. Strange that for you it only happens in those two programs, and only when they are fullscreen. Maybe it's two similar but distinct bugs?
This bug is happening to me on an Nvidia machine and an Intel machine. Seems to happen to me while playing random video games and alt tabbing to firefox or jetbrains rider a lot.
This seems reproducible when toggling compositing. Contents are garbage when we suspend compositing, and still broken when we re-enable.
This also happens with me on Steam randomly. Running Arch Linux (kernel 5.19.1-arch2-1) and on Plasma 5.25.4.
Same bug here, KDE Plasma 5.25.4, Archlinux(5.19.4-arch1-1), X11, Intel
Same bug here, Plasma 5.25.4, Wayland, GPU: AMD RENOIR (LLVM 14.0.6, DRM 3.47, 5.19.4-zen1-1-zen) in AMD 5800H, Mesa 22.1.7.0, Firefox nightly 106.0a1.20220827.19, Arch Linux
I seem to be experiencing the same problem - have Firefox running with several windows, lots of tabs (hundreds) using the vertical "tree tabs" extension, and after a while, sometimes many hours, a FF windows starts flickering between two static frames - especially on, say, videos playing or video conference video (e.g. BigBlueButton) - and the refresh of all the FF windows stops updating unless I move/resize the window, and then it just redraws once before freezing again... Running KDE Neon 20.04 on an AMD CPU desktop machine (with X11 and AMD graphics, and 5.19.5 kernel). This problem has happened with other kernels. Haven't tried a non-plasma desktop for a while, so can't remember it happening on one, but I might be wrong.
Oops - and I should say I'm running Plasma 5.25.4 and KDE Frameworks 5.97.0
*** Bug 431446 has been marked as a duplicate of this bug. ***
Created attachment 151963 [details] Same bug when it happens to a Plasma panel
Same here. Operating System: openSUSE Leap 15.4 KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Kernel Version: 5.14.21-150400.24.18-default (64-bit) Graphics Platform: X11
looks like a duplicate of https://bugs.kde.org/show_bug.cgi?id=449301 maybe
See also https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/51
This *might* be Qt related - I'm experiencing a similar problem on Lubuntu 22.04.1 with LXQt and Openbox on one system over here. Yes, I know that's not KDE, but KDE and LXQt both use Qt, so perhaps the problem is there? Might be totally unrelated, just throwing that out there in case it turns out to be helpful.
(In reply to Aaron Rainbolt from comment #17) > This *might* be Qt related - I'm experiencing a similar problem on Lubuntu > 22.04.1 with LXQt and Openbox on one system over here. Yes, I know that's > not KDE, but KDE and LXQt both use Qt, so perhaps the problem is there? > Might be totally unrelated, just throwing that out there in case it turns > out to be helpful. VLC uses Qt, but FF does not. What compositing manager do you use?
(In reply to Vlad Zahorodnii from comment #18) > (In reply to Aaron Rainbolt from comment #17) > > This *might* be Qt related - I'm experiencing a similar problem on Lubuntu > > 22.04.1 with LXQt and Openbox on one system over here. Yes, I know that's > > not KDE, but KDE and LXQt both use Qt, so perhaps the problem is there? > > Might be totally unrelated, just throwing that out there in case it turns > > out to be helpful. > > VLC uses Qt, but FF does not. What compositing manager do you use? I don't think Lubuntu uses any compositor at all by default. The WM is Openbox, Compton *can* be enabled but usually isn't. VLC isn't used much on this system and I've not experienced any problems with it, but Firefox is used quite frequently and this behavior happens somewhat frequently with it.
*** Bug 459138 has been marked as a duplicate of this bug. ***
I get this on both x11 (with either modesetting ddx or intel ddx) and wayland (with MOZ_ENABLE_WAYLAND=1), and switching windows often updates its content. There are subtle differences though, which may indicate that multiple issues are involved here: - On X11, sometimes when tab content is not being updated, a big rectangle area (centered, probably 1920x1080 out of 2560x1440) is affected and frozen but the space around it is still being updated correctly (like scrolling the webpage). Switching windows only updates the whole tab once. - On Wayland, the tab content is often correctly updated all the time, but switching tabs doesn't work and the old tab is still operational. Switching windows will make the tab switching actually happen, for once. Plasma 5.25.5 KDE Frameworks 5.98.0 Qt 5.15.6+kde+r177 Linux 5.19.10
If the bug can be seen on Wayland, it can be a new bug in Firefox. CC stransky
(In reply to Felix Yan from comment #21) > I get this on both x11 (with either modesetting ddx or intel ddx) and > wayland (with MOZ_ENABLE_WAYLAND=1), and switching windows often updates its > content. I personally have never seen freezing on wayland. On X11, can you check whether kwin prints BadIdChoice errors in its logs (journalctl --user-unit plasma-kwin_x11) when firefox starts freezing
It may be caused on Firefox side by depleted file descriptor poll - Firefox fails to allocate new buffers to draw into so transparent window is provided. Check journal if you see any error messages.
(In reply to Vlad Zahorodnii from comment #23) > On X11, can you check > whether kwin prints BadIdChoice errors in its logs (journalctl --user-unit > plasma-kwin_x11) when firefox starts freezing I have searched the journal since April and got no BadIdChoice results. The log is flooded with BadWindow/BadDamage/BadDrawable though.
(In reply to Martin Stransky from comment #24) > It may be caused on Firefox side by depleted file descriptor poll - Firefox > fails to allocate new buffers to draw into so transparent window is > provided. Check journal if you see any error messages. I have seen nothing strange from Firefox :( Since reproducing this takes over 24h I'll give it another try on next reproduction.
I would tend to exclude a bug in Firefox, considering it also happens with Slack, which is basically Electron and therefore Chromium.
Indeed, the Xorg specific behavior (rectangle region not being updated) could be reproduced by multiple application here too, including Telegram Desktop (Qt6), VSCode (Electron), virt-manager (GTK3).
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/3022
Git commit b3214db0b7aff89a82dbc4769f22c548f55863cf by Vlad Zahorodnii. Committed on 05/10/2022 at 07:10. Pushed by vladz into branch 'master'. x11: Make damage region fetching code more robust to errors With DamageReportNonEmpty damage report level, the x server will send kwin a DamageNotify when the damage region changes from empty to not empty. The damage region will be made empty when SurfaceItemX11 calls xcb_damage_subtract(). It appears like xcb_generate_id() can return us an already associated XID, which eventually results in xcb_damage_subtract() failing and breaking state tracking in SurfaceItemX11. KWin will no longer receive DamageNotify events and some windows will freeze. In order to make getting BadIdChoice less catastrophic, this change makes the SurfaceItemX11 reset m_isDamaged after successfully fetching the damage region. If xcb_generate_id() returns us a bad id, kwin will try to fetch the damage again in the next frame. M +1 -1 src/surfaceitem_x11.cpp https://invent.kde.org/plasma/kwin/commit/b3214db0b7aff89a82dbc4769f22c548f55863cf
Git commit 062afee75bd61e225d72b89c2b5e413e61cd23d8 by Nate Graham, on behalf of Vlad Zahorodnii. Committed on 05/10/2022 at 18:35. Pushed by ngraham into branch 'Plasma/5.26'. x11: Make damage region fetching code more robust to errors With DamageReportNonEmpty damage report level, the x server will send kwin a DamageNotify when the damage region changes from empty to not empty. The damage region will be made empty when SurfaceItemX11 calls xcb_damage_subtract(). It appears like xcb_generate_id() can return us an already associated XID, which eventually results in xcb_damage_subtract() failing and breaking state tracking in SurfaceItemX11. KWin will no longer receive DamageNotify events and some windows will freeze. In order to make getting BadIdChoice less catastrophic, this change makes the SurfaceItemX11 reset m_isDamaged after successfully fetching the damage region. If xcb_generate_id() returns us a bad id, kwin will try to fetch the damage again in the next frame. (cherry picked from commit b3214db0b7aff89a82dbc4769f22c548f55863cf) M +1 -1 src/surfaceitem_x11.cpp https://invent.kde.org/plasma/kwin/commit/062afee75bd61e225d72b89c2b5e413e61cd23d8
Thanks for the patch, I applied this patch to 5.25.5 version of kwin, let's see whether it solves the issue.
*** Bug 343661 has been marked as a duplicate of this bug. ***
Updated to 5.26, this bug is still happening to me
(In reply to Jessica M from comment #34) > Updated to 5.26, this bug is still happening to me I have been running 5.26 for a few days and haven't seen the bug. Are you using NVIDIA?
(In reply to Fushan Wen from comment #35) > (In reply to Jessica M from comment #34) > > Updated to 5.26, this bug is still happening to me > > I have been running 5.26 for a few days and haven't seen the bug. > > Are you using NVIDIA? Yes
same here
Since installing 5.26 a few days ago, I have not seen the issue. I've got an AMD graphics card (Radeon RX 550) and am running kernel 5.19.14-051914-generic.
(In reply to Dave Lane from comment #38) > AMD graphics card (Radeon RX 550) and am running kernel Oops - should be RX 5500
*** Bug 449301 has been marked as a duplicate of this bug. ***
(In reply to Jessica M from comment #36) > Yes If so it's likely a different bug because the fix is for BadDamage only. Please subscribe to https://bugs.kde.org/show_bug.cgi?id=429211 or file a new bug.
*** Bug 456608 has been marked as a duplicate of this bug. ***