SUMMARY title STEPS TO REPRODUCE 1. open a bunch of windows (~ 70 should make the issue very prominent) 2. open htop 3. take note of memory used 4. win+w a bunch of times OBSERVED RESULT memory consumption keeps growing every other show/hide cycle by some 50-100MB SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.90.90 KDE Frameworks Version: 5.247.0 Qt Version: 6.6.1 Kernel Version: 6.2.0-39-generic (64-bit) Graphics Platform: offscreen Processors: 12 × AMD Ryzen 5 3600X 6-Core Processor Memory: 31.2 GiB of RAM Graphics Processor: AMD Radeon RX 5700 XT ADDITIONAL INFORMATION /proc/meminfo top deltas between two measurements with some show/hide cycles in between: "Slab:": 4084, "SUnreclaim:": 4300, "Active(anon):": 9480, "AnonPages:": 17384, "DirectMap4k:": 26624, "Cached:": 620052, "Shmem:": 636524, "Inactive:": 640840, "Inactive(anon):": 641936, "Committed_AS:": 648580 It may be of note that when I strace kwin with -e %memory it produces an unbalanced amount of mmap(, munmap( calls
The leak seems to happen much more when running a game. Case in point when I have steam open + the game Dorfromantik (+firefox,dolphin,telegram,element,discord,bottles) I get a some 100M leaked every cycle.
Some more findings: running a bunch of fullscreen glxgears also seems to help produce the leak. Also, as further confirmation that we are leaking mappings: /proc/pid/maps keeps growing new maps after each overview. Unfortunately due to the amount of mmap calls it's a bit awkward to debug this further. Will probably need some scripting to trace call stacks and then filter out all the ones that were unmapped again :/
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4942
Git commit 203c4998bca5a949f05c495040ecce5e4a6d4eeb by David Redondo. Committed on 16/01/2024 at 13:45. Pushed by davidre into branch 'master'. Make sure window thumbnails and Qt Quick resources are destroyed properly Drops the doneCurrent as it was preventing proper cleanUp because no context was current when textures were deleted. Also avoid manipulating the context when Qt has the current one, as various Qt classes have guards around their cleanup handlers which rely on a current Qt context. Despite the comment the order of render control and view destruction needs to be switched as the QQuickWindow destructor calls into the render control to notify if of window destruction. Related: bug 479846 FIXED-IN:6.0 M +1 -2 src/effect/offscreenquickview.cpp M +10 -10 src/scripting/windowthumbnailitem.cpp https://invent.kde.org/plasma/kwin/-/commit/203c4998bca5a949f05c495040ecce5e4a6d4eeb
Git commit 228ef989b4264b9cbac029c00d399dfb9f4bd0c2 by Vlad Zahorodnii, on behalf of David Redondo. Committed on 16/01/2024 at 14:34. Pushed by vladz into branch 'Plasma/6.0'. Make sure window thumbnails and Qt Quick resources are destroyed properly Drops the doneCurrent as it was preventing proper cleanUp because no context was current when textures were deleted. Also avoid manipulating the context when Qt has the current one, as various Qt classes have guards around their cleanup handlers which rely on a current Qt context. Despite the comment the order of render control and view destruction needs to be switched as the QQuickWindow destructor calls into the render control to notify if of window destruction. Related: bug 479846 FIXED-IN:6.0 (cherry picked from commit 203c4998bca5a949f05c495040ecce5e4a6d4eeb) M +1 -2 src/effect/offscreenquickview.cpp M +10 -10 src/scripting/windowthumbnailitem.cpp https://invent.kde.org/plasma/kwin/-/commit/228ef989b4264b9cbac029c00d399dfb9f4bd0c2
*** Bug 480100 has been marked as a duplicate of this bug. ***