SUMMARY I just tried the new Plasma 5.16 beta on Archlinux, and when the Wayland session starts, Kwin eats all the RAM in a few seconds and the session hangs. I've read that Plasma 5.16 needs Frameworks 5.59 but Archlinux still has 5.58, even with the kde-unstable repo that provides Plasma 5.16 beta. I don't know if it's Wayland-specific, as I did not try with X11. STEPS TO REPRODUCE 1. Start a Wayland session 2. Wait a few seconds 3. The desktop becomes unresponsive and all the RAM is used by the kwin_wayland process. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
The part about needing 5.59 isn't true. Please try with x11.
(In reply to David Edmundson from comment #1) > The part about needing 5.59 isn't true. > > Please try with x11. I seem to be experiencing the same issue. Hardware: intel 7700hq, no discrete graphics enabled, just using the igpu. This only seems to happen on a wayland session, and does not occur when running on x. What can I do to help track it down?
run "dbus-launch kwin_wayland" from inside X You can then add WAYLAND_DISPLAY=wayland-0 dolphin --platform wayland etc. to add some apps into this wayland session Then we can see if we can reproduce the issue in that environment
(In reply to David Edmundson from comment #3) > run > > "dbus-launch kwin_wayland" from inside X > > > You can then add > > WAYLAND_DISPLAY=wayland-0 dolphin --platform wayland > etc. > > to add some apps into this wayland session > > > Then we can see if we can reproduce the issue in that environment trying to run dolphin inside nested kwin with --platform wayland doesn't seem to work, citing > qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even though it was found. just launching pure kwin_wayland from an x session seems to work, but does not produce a detectable memory leak
I found the culprit by resetting all my themes settings to Default Breeze and re-enabling them one by one : it's the window decoration. If I change from Breeze windeco to anything else, the bug occurs.
Normally I would say, "it's a bug with those themes, please report this to their developers", but it seems slightly less likely in this case since it's *every* other theme. Still possible of course, but maybe needs an investigation here first.
It seems as though oxygen works without problems as well, but nothing other than that and breeze.
And you don't see this same leak with non-breeze on X? Can you see if changing the render loop in "kcmshell5 qtquicksettings" makes a difference Also confirm that leaving it as breeze but using the alt-tab switcher causes a smaller leak.
(In reply to David Edmundson from comment #8) > And you don't see this same leak with non-breeze on X? > > Can you see if changing the render loop in "kcmshell5 qtquicksettings" > makes a difference > > Also confirm that leaving it as breeze but using the alt-tab switcher causes > a smaller leak. Changing the render loop does not seem to cause the leak with breeze enabled, but I'll check if with another theme (that would cause a memory leak) enabled it makes a difference.
(In reply to David Edmundson from comment #8) > And you don't see this same leak with non-breeze on X? > > Can you see if changing the render loop in "kcmshell5 qtquicksettings" > makes a difference > > Also confirm that leaving it as breeze but using the alt-tab switcher causes > a smaller leak. Non-breeze on x does not have the leak If I use a theme that *would* have the leak on wayland, and try changing the render loop between basic, threaded, and automatic, the leak persists and does not go away.
Not sure if this would help track it down any further, but it seems that changing the theme back within the same session brings performance back to normal and the memory lost initially is fully recovered. So it's not a leak per se, as it is kept track of enough to free later.
Just installed KDE 5.16 (not beta) on kde neon. I can confirm the memory leak stil present.
OK, I noticed something interesting : with some themes, the bug does not happen, eg. : SierraBreezeEnhanced.
(In reply to Sawyer Bergeron from comment #11) > Not sure if this would help track it down any further, but it seems that > changing the theme back within the same session brings performance back to > normal and the memory lost initially is fully recovered. So it's not a leak > per se, as it is kept track of enough to free later. It does not on my system. Changing the theme does not help.
(In reply to tromzy from comment #14) > (In reply to Sawyer Bergeron from comment #11) > > Not sure if this would help track it down any further, but it seems that > > changing the theme back within the same session brings performance back to > > normal and the memory lost initially is fully recovered. So it's not a leak > > per se, as it is kept track of enough to free later. > > It does not on my system. Changing the theme does not help. Do you mean changing from one affected theme to another or from a theme that comes with a leak back to Breeze or some unaffected theme? For me the latter undoes the leak, the former does not.
Can confirm it also on openSUSE Tumbleweed. X11 is unaffected Theme: Adapta Operating System: openSUSE Tumbleweed 20190612 KDE Plasma Version: 5.16.0 KDE Frameworks Version: 5.58.0 Qt Version: 5.12.3 Kernel Version: 5.1.7-1-default OS Type: 64-bit Processors: 8 × AMD Ryzen 7 2700U with Radeon Vega Mobile Gfx Memory: 15,4 GiB
(In reply to alexander.reimelt from comment #16) > Can confirm it also on openSUSE Tumbleweed. > X11 is unaffected Only changing the window decoration from breeze to something else is triggering the bug on my system, color and icon themes are unaffected. After going back to breeze the performance recovers but the memory won't get freed. Even setting everything back to breeze won't recover the lost memory. Somehow going from affected decoration to affected decoration to breeze decoration will recover some lost memory (in my case plastik -> adapta -> breeze).
I can confirm the bug on my end. At first, I thought it's about window theme so I switched from kvantum to Breeze, no effect, heavy memory leak still occurred on kwin-wayland. I noticed that the Aurorae theme (window decoration theme) was not properly displayed I switched from Breezmite to Breeze and... it fixed the issue, memory leak stopped. The issue happened on Intel proprietary drivers, didn't dare to test Nvidia in such case. The memory leak was too severely crippling the system so it was even hard to take any screenshot. In a matter of seconds, memory and CPU were used and hang. Operating System: Manjaro Linux KDE Plasma Version: 5.16.1 KDE Frameworks Version: 5.59.0 Qt Version: 5.12.4 Kernel Version: 5.1.12-1-MANJARO OS Type: 64-bit Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz Memory: 7,7 GiB
Created attachment 121070 [details] kwin-wayland-memory-leak-non-breeze-aurorae-theme You can see on the screenshot how RAM usage is increasing at a rapid pace, CPU is busy (the whole desktop session is very choppy because of that and then hangs). On processes card, it's visible that kwin-walaynd is eating RAM and CPU but I didn't manage to do a second screenshot. RAM increase was too high and too quick. You can also see the lack of proper titlebar (Aurorae theme Breezmite) which is causing the issue with kwin-wayalnd. Again, when I switched to Breeze aurorae theme, there was no memory leak on wayaland session.
Looks like KWin falls into some sort of an infinite loop. It keeps creating InternalClient.
Plasma/5.15 is good. I'll start bisecting.
git bisect start # good: [a1c443cbcd43af18e654704c4f7d848a4b6669c2] SVN_SILENT made messages (.desktop file) - always resolve ours git bisect good a1c443cbcd43af18e654704c4f7d848a4b6669c2 # bad: [e8fe3f2fb7195fe562a073d1a78eb05d74670cfd] SVN_SILENT made messages (.desktop file) - always resolve ours git bisect bad e8fe3f2fb7195fe562a073d1a78eb05d74670cfd # good: [57440d1d6b490cdad51266977d0269a08918b82f] Fix captions with non-BMP characters git bisect good 57440d1d6b490cdad51266977d0269a08918b82f # bad: [5eb28512dd077998a6be2ff8aa6262a3c4f4f9af] Use new window decoration theme icon for the Window Decorations KCM git bisect bad 5eb28512dd077998a6be2ff8aa6262a3c4f4f9af # good: [beb35d8b8fb6d2aebfcc625fbbdf18244f0e1817] SVN_SILENT made messages (.desktop file) - always resolve ours git bisect good beb35d8b8fb6d2aebfcc625fbbdf18244f0e1817 # bad: [40477aff2d8178eb99b8e5f7d6bae6076ef4bffe] SVN_SILENT made messages (.desktop file) - always resolve ours git bisect bad 40477aff2d8178eb99b8e5f7d6bae6076ef4bffe # good: [6e08fb2fa5f6f2d03d9ad5ef74519295357c6ba2] [xwl] Generic X selections translation mechanism with Clipboard support git bisect good 6e08fb2fa5f6f2d03d9ad5ef74519295357c6ba2 # good: [062dfefafe06629117abf37b68ef59964fbb9654] [platforms/hwcomposer] Port to AbstractOutput git bisect good 062dfefafe06629117abf37b68ef59964fbb9654 # bad: [06f64d5e567e951ffe355f4b12af8ba3f83225b8] [autotests] Sub-surface resize test git bisect bad 06f64d5e567e951ffe355f4b12af8ba3f83225b8 # bad: [9b922f88332fc470dcb50e9b55c7d69ab7da4d4c] Split out a dedicated InternalClient class git bisect bad 9b922f88332fc470dcb50e9b55c7d69ab7da4d4c # good: [66faa480d414eb5844ef7ff74c4643716a87f7f2] SVN_SILENT made messages (.desktop file) - always resolve ours git bisect good 66faa480d414eb5844ef7ff74c4643716a87f7f2 # first bad commit: [9b922f88332fc470dcb50e9b55c7d69ab7da4d4c] Split out a dedicated InternalClient class
Oops, sorry. Though I don't understand why: Aurorae should not create any internal windows at all...
(In reply to Martin Flöser from comment #23) > Oops, sorry. Though I don't understand why: Aurorae should not create any > internal windows at all... Qt asks our QPA to create a QPlatformWindow for each QOffscreenSurface, which never gets mapped.
After a bit of testing, it looks like internal_client.cpp#L40 [1] causes this bug. Though I'm not sure how exactly KWin falls in the infinite "loop." [1] Commit hash: 9b922f88332fc470dcb50e9b55c7d69ab7da4d4c
I am also affected by this bug. Simply running "kwin_wayland --exit-with-session termite" from a TTY starts a KWin session, but eats the whole RAM in a matter of seconds (I picked termite as an application because it has native Wayland support and allows me to see the RAM usage, but Konsole running through XWayland gave the same result). Distribution: Archlinux Kernel: 5.1.15-arch1-1-ARCH KDE Plasma Version: 5.16.2 KDE Frameworks Version: 5.59.0 Qt Version: 5.12.4 GPU : Intel HD Graphics 630 (driver: i915) I also have an Nvidia GPU in the machine (it's an Optimus laptop) but the bug happens even when it's powered off with its modules unloaded.
Git commit 61956025f0801170692c02d313ddc324e27e9c6c by Vlad Zagorodniy. Committed on 28/06/2019 at 22:24. Pushed by vladz into branch 'Plasma/5.16'. Decorate only toplevel internal clients Summary: Unfortunately Aurorae decoration engine creates several internal clients per each decoration. One of those clients represents QOffscreenSurface, which is not a toplevel. Given that no QWindow object will be found for such clients, m_internalWindowFlags contains undefined value. Luckily, QOffscreenSurface sets FramelessWindowHint flag, but because InternalClient is not able to find matching QWindow object, cached QWindow flags won't have that hint set. Thus InternalClient will attempt to decorate QOffscreenSurface. A new Aurorae decoration will be created, which means a new QOffscreenSurface will be created, which means a new Aurorae decoration will be created, and so on. This change restricts subset of internal clients that can be decorated. Only clients with valid m_internalWindow can be decorated. If m_internalWindow isn't null, then m_internalWindowFlags is guaranteed to be valid as well. FIXED-IN: 5.16.3 Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22136 M +13 -1 internal_client.cpp https://commits.kde.org/kwin/61956025f0801170692c02d313ddc324e27e9c6c
Git commit f5b66a583de4ddfc6982d5bc54a307476077fc0f by Vlad Zagorodniy. Committed on 01/07/2019 at 19:04. Pushed by vladz into branch 'master'. [plugins/qpa] Implement native offscreen surface Summary: Depending on whether the underlying platform supports offscreen surfaces, QOffscreenSurface may create an invisible QWindow. In our case that's the case, for each offscreen surface a native window is created. This may lead to some funky results related to window decorations, see bug 407612. There are several ways to implement offscreen surfaces - either use pbuffers or utilize a surfaceless context extension. For the sake of simplicity this change sticks with pbuffers, but it's a good idea to support both methods. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, alexeymin, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22150 M +1 -0 plugins/qpa/CMakeLists.txt M +6 -0 plugins/qpa/integration.cpp M +1 -0 plugins/qpa/integration.h A +82 -0 plugins/qpa/offscreensurface.cpp [License: GPL (v2)] A +53 -0 plugins/qpa/offscreensurface.h [License: GPL (v2)] M +34 -22 plugins/qpa/sharingplatformcontext.cpp https://commits.kde.org/kwin/f5b66a583de4ddfc6982d5bc54a307476077fc0f