Bug 406303 - Task Manager eats up open file descriptors on X server until maximum reached
Summary: Task Manager eats up open file descriptors on X server until maximum reached
Alias: None
Product: plasmashell
Classification: Plasma
Component: Task Manager and Icons-Only Task Manager (show other bugs)
Version: 5.14.5
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: 1.0
Assignee: Eike Hein
: 406205 407329 (view as bug list)
Depends on:
Reported: 2019-04-07 15:38 UTC by Juha Nikkanen
Modified: 2019-05-09 15:11 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:

dmesg-5.0.5-200.fc29.x86_64 (91.49 KB, text/plain)
2019-04-07 15:38 UTC, Juha Nikkanen

Note You need to log in before you can comment on or make changes to this bug.
Description Juha Nikkanen 2019-04-07 15:38:56 UTC
Created attachment 119283 [details]

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)'

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

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

Task Manager / Plasmashell shall release rendering related memory gracefully

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

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:
Comment 1 Christoph Feck 2019-04-25 10:17:46 UTC
*** Bug 406205 has been marked as a duplicate of this bug. ***
Comment 2 Kai Uwe Broulik 2019-04-25 10:23:10 UTC
Probably the composite handling windowthumbnail does, can confirm the number of fds grows
Comment 3 Kai Uwe Broulik 2019-04-25 10:45:00 UTC
Thanks for your investigation: I'd appreciate if you could try this patch: https://phabricator.kde.org/D20805
Comment 4 Juha Nikkanen 2019-04-25 12:51:22 UTC
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?
Comment 5 Christoph Feck 2019-04-25 12:57:59 UTC
The bug will get closed when the patch is committed to the git repository.
Comment 6 Kai Uwe Broulik 2019-04-25 13:05:00 UTC
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

Comment 7 Nate Graham 2019-05-09 15:11:03 UTC
*** Bug 407329 has been marked as a duplicate of this bug. ***