Huge xdg-document-portal memory usage when searched recursively

[tim77]

Hi. xdg-document-portal can occupy a lot of RAM space. 2400+ MB and continue growing.

How to reproduce

Go via Nautilus to /proc/$PID/root (where $PID is your flatpak app which running) and search via Nautilus for some file. Wait for results.

Actual results

And it continues growing until i manually stopped search.

Why and what i search here?

I had to find some content which was created in tmps by WINE Flatpak package.

System info

OS: Fedora 32 Flatpak: 1.7.3-1 xdg-desktop-portal: 1.7.2-1

[tim77]

I found another case which could have more sense probably: memory leak happens when running dua (Utility for view disk space usage and delete unwanted data) on root / partition.

But baobab (GNOME utility) handles fine this case without issue, so maybe this could interpreted more like dua bug itself, i don't know.

[naught101]

I'm seeing this too, on Kubuntu 22.04, but installed via apt.

Killing it seems to be an OK thing to do? But then I don't use many flatpak apps.

[gentoo-root]

In my case, xdg-desktop-portal-gnome ate 5.7 GiB of RAM. systemctl --user stop xdg-desktop-portal-gnome.service worked as an immediate workaround (the service restarts when it's needed next time), but such memory consumption is far from normal for a service that idles most of the time.

[smcv]

In my case, xdg-desktop-portal-gnome ate 5.7 GiB of RAM

xdp-gnome is not maintained by this project. If you have a way to reproduce that large memory use, or other information that would be useful for figuring out why it did this, please report it to https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome. (If not, then mentioning that its memory use is high is not really something that anyone can fix.)

[smcv]

Go via Nautilus to /proc/$PID/root (where $PID is your flatpak app which running) and search via Nautilus for some file

I found another case which could have more sense probably: memory leak happens when running dua (Utility for view disk space usage and delete unwanted data) on root / partition

These are both doing a recursive crawl through the filesystem. xdg-document-portal provides a virtual filesystem using FUSE, so I suspect that what's happening here is that the search is causing some sort of infinite recursion, which forces xdg-document-portal to allocate memory for all the (potentially infinitely many?) directories that have been searched.

[sophie-h]

I suspect hitting the same issue with rust-analyzer inside Flatpaks regularly. The document portal fills the memory (32 GB) until the system completely freezes and I have to reset it.

[iihmsunn]

Not sure if this is the same bug but I found a way to consistently replicate xdg-document-portal causing OOM on my 16gb ram machine. I'm playing Baldur's Gate 3 (gog version) using Heroic launcher flatpak. Not sure if it matters but the game itself is located in ~/Games and wine prefix is somewhere in ~/Games/Heroic

By the time the game reaches the main menu, xdg-document-portal is using about 400mb ram. When you load into a game, it's 800mb. If you save and reload, it's 1.2gb, etc, and eventually after some hours it causes the entire system to freeze since it never frees any memory. This may actually be happening with any game, haven't tested

[hfiguiere]

I can't seem to reproduce with 1.18.2.

I wonder if that's not related to #689.

[Francewhoa]

This is to confirm this challenge with 1.16.0-2

We have one device using more than 11 Gb for xdg-desktop-portal

Using:

• Debian 12 Bookworm
• 64-bits
• GNOME 43.9
• Wayland

[Francewhoa]

Steps to reproduce:

1. Install this awesome Flatpak app at https://flathub.org/apps/io.github.cboxdoerfer.FSearch For those not familiar with FSearch, it "helps you to find files and folders as easy and fast as possible. Just type a few letters and search results will appear almost instantly."

2. Configure FSearch to include all system files located at / Which includes lots of system Symlinks. Plus 20 or more large storages. Both local and remote.

3. Install BackInTime from https://packages.debian.org/bookworm/backintime-qt

4. Using BackInTime, start a large backup. Between 8 and 24 Tb. With millions of files.

5. Configure FSearch to exclude from its database all folders, files, medias use by BackInTime

6. While the above BackInTime (root) backup is running, using FSearch, start a search.

7. After a few FSearch searches, xdg-document-portal starts leaking large amount of memories. Into the Gb. As you know, xdg-document-portal is included in xdg-desktop-portal.

We were able to reproduce this multiple times during the last days. Including after clean reboots.

Using:

• Debian 12 Bookworm
• 64-bits
• GNOME 43.9
• Wayland

[GeorgesStavracas]

@Francewhoa 1.16.0 is too old, you have to test this with at least 1.18.1

[Francewhoa]

For those facing this challenge, this temporary fix worked for us:

1. Save valuable data
2. Force Stop or Kill xdg-document-portal process
3. Memory is freed. BackInTime and FSearch do not seem affected by the above. But obviously we temporarily lost the benefits of xdg-document-portal.
4. Challenge is back later with the same steps to reproduce in my other comment above. But at least valuable data was not lost and device did not freeze.

[Francewhoa]

@Francewhoa 1.16.0 is too old, you have to test this with at least 1.18.1

Thanks for your suggestion @GeorgesStavracas :) I'll happily pass your suggestion to our IT team.

It's unlikely that they will install 1.18.1 or more recent on this device. Because it is a production devise. Not meant for testing. On Debian 12 Bookworm, the latest version presently available is this 1.16.0-2. There is presently no more recent version in the repository Backport.

When I pass on your suggestion, I'll add another suggestion about trying a recent Flatpak version of xdg-desktop-portal from https://flatpak.github.io/xdg-desktop-portal/