Created attachment 119283 [details] dmesg-5.0.5-200.fc29.x86_64 SUMMARY After longish use of KDE Plasma session, Xorg server runs out of file handles (a count of 1024 by default). I.e. /proc/`pidof Xorg`/fd fills up an anonymous file entries like: ... lrwx------. 1 root root 64 Apr 6 10:55 95 -> '/memfd:xshmfence (deleted)' lrwx------. 1 root root 64 Apr 6 13:18 96 -> '/memfd:xshmfence (deleted)' lrwx------. 1 root root 64 Apr 6 10:55 97 -> '/memfd:xshmfence (deleted)' lrwx------. 1 root root 64 Apr 6 10:55 98 -> '/memfd:xshmfence (deleted)' lrwx------. 1 root root 64 Apr 6 10:55 99 -> '/memfd:xshmfence (deleted)' ... STEPS TO REPRODUCE 1. login to Plasma session 2. open dozens of applications so that Task Manager starts grouping task instances 3. observe content of /proc/`pidof Xorg`/fd by commands ls and wc 4. induce creation of memfd:xshmfence fds by hovering on panel (Task Manager), over group of open tasks so that Task Manager shows thumbnails of windows of open applications. This step will increase leaked fds by number of window thumbnails of hovered group 5. move mouse pointer so that group popup disappears 6. repeat from 3. until system file limit is hit OBSERVED RESULT When Xorg has run out of system file limit, random problems start to appear: - key bindings may lost and/or have no desired effect - mouse clicks / drags have no effect - $HOME/.cache corrupts somehow - system requires reboot and possibly restore of $HOME/(.cache|.config|.kde|.local) from backup EXPECTED RESULT Task Manager / Plasmashell shall release rendering related memory gracefully SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 29, kernel 5.0.5 / Plasma5 (available in About System) KDE Plasma Version: 5.14.5 KDE Frameworks Version: 5.55.0 Qt Version: 5.11.3 ADDITIONAL INFORMATION Hovering on Pager or on System Tray in a such way that popup window appears does not consume an anonymous file handles on X server permanently. Only via Task Manager does. Also, if running application is minimized so that only enlarged app icon is shown on group popup (instead of window thumbnail), Task Manager does not leak memfd handles I created a bug on RHBZ already: https://bugzilla.redhat.com/show_bug.cgi?id=1696961
*** Bug 406205 has been marked as a duplicate of this bug. ***
Probably the composite handling windowthumbnail does, can confirm the number of fds grows
Thanks for your investigation: I'd appreciate if you could try this patch: https://phabricator.kde.org/D20805
Kai, with your patch, problem solved. I made a local .rpm where I applied your patch and updated & rebooted (updated kernel too) and no able to trigger cumulative xshmfence handles since then. Thank you very much! I think I dare to close this bug now?
The bug will get closed when the patch is committed to the git repository.
Git commit 1b2424879a198af3de2988f64182d70e6c0c199e by Kai Uwe Broulik. Committed on 25/04/2019 at 13:04. Pushed by broulik into branch 'master'. [Window Thumbnail] Also monitor scene visibility and clean up Just because the item is visible doesn't mean the window itself is. Keep track of the window it's in. Use itemChange instead of connects and move the check for starting to startRedirect so we don't have to check the conditions for that in every change handler (visible && enabled && window->visible). It also saves three connects in the constructor. Also, don't unredirect if we didn't redirect in the first place to avoid warnings printed on console. Differential Revision: https://phabricator.kde.org/D20805 M +62 -32 src/declarativeimports/core/windowthumbnail.cpp M +7 -1 src/declarativeimports/core/windowthumbnail.h https://commits.kde.org/plasma-framework/1b2424879a198af3de2988f64182d70e6c0c199e
*** Bug 407329 has been marked as a duplicate of this bug. ***