Major VRAM + RAM leak in FileChooser Portal
Took a while to figure out why my system was constantly running out of VRAM.
It's a leak in xdg-desktop-portal-gnome. The leaked memory is never returned. And it is a major impediment for game performance. Not to mention that AI tools will constantly complain about "no available VRAM" due to xdg-desktop-portal-gnome hogging it all.
I run into this issue every day, since its memory leak grows so fast.
- Affected systems: Fedora 38, Fedora 39, both using Xorg.
-
/usr/libexec/xdg-desktop-portal-gnome --version: xdg-desktop-portal-gnome 45.1
(Fedora 39),xdg-desktop-portal-gnome-44.2-1.fc38
(Fedora 38). sudo dnf list "gtk4*": 4.12.4-1.fc39
Every time the FileChooser dialog opens, it leaks memory proportional to how many thumbnails are in the dialog. Scrolling past the thumbnails further leaks a bit more memory (compared to just closing the dialog immediately).
I wrote a small test application and recorded the VRAM + RAM growth over time. In this particular example, it grows VRAM by 25-30 MiB per dialog (~25 MiB if you close it immediately, ~30 MiB if you scroll past more thumbnails before closing it), but there's some variability going on because I have actually seen it grow by 100+ MiB VRAM every time the FileChooser is used, in other sessions!
I've recorded video of the leak in action. At the end, xdg-desktop-portal-gnome is using 5202 MiB VRAM and 2740 MiB System RAM, and those numbers will just continue growing over time as the system is being used more.
If this particular example video had grown at the higher "~100 MiB VRAM leak per dialog" rate which I have often observed, then we would actually have ended up at 20808 MiB VRAM leaked. Which I have encountered many times, and that is indeed a problem for computer stability. ;)
Releasing the leaked memory can only be done via systemctl restart --user xdg-desktop-portal-gnome
.
Test application and video are attached below. Hopefully they help with debugging.