Huge memory consumtion

[azzamsa]

Hi.

Flatpak 1.14.4
Debian GNU/Linux 12 (bookworm)
Wayland

Related: https://github.com/flatpak/flatpak/issues/3386

[cristianadrielbraun]

You think that's huge?: :laughing:

[zroug]

I also have this problem.

I noticed that for me it only affects applications that make heavy use of the org.freedesktop.Flatpak portal, such as Black Box. But it's entirely possible that this is just a coincidence.

[azzamsa]

I noticed that for me it only affects applications that make heavy use of the org.freedesktop.Flatpak portal, such as Black Box. But it's entirely possible that this is just a coincidence.

Yes, I am using BlackBox. I also plan to replace it because it uses a considerable amount of memory just to run the terminal app. How to know which app uses org.freedesktop.Flatpak portal?

[zroug]

You can show the permissions of an application with flatpak info --show-permissions. I don't know of a native way to show all apps with a specific permission but you could use this quick and dirty command:

flatpak list --app --columns=ref:f | xargs -i sh -c "flatpak info --show-ref --show-permissions {} | grep -zF org.freedesktop.Flatpak=talk | head -n 1"

To be clear, I have no reason to belive that this issue has anything to do with the org.freedesktop.Flatpak portal itself. I was just thinking that it might be very noticeable here because of the amount of data being transferred.

[cristianadrielbraun]

Well I'm using Black Box too so at least we're 3 of 3 so far. Of course I'm willing to change the app since 10gb for a terminal it's a little bit excessive but there's definitely some root common cause

[azzamsa]

but you could use this quick and dirty command:

🦄 flatpak list --app --columns=ref:f | xargs -i sh -c "flatpak info --show-ref --show-permissions {} | grep -zF org.freedesktop.Flatpak=talk | head -n 1"
app/com.github.johnfactotum.Foliate/x86_64/stable
app/com.github.liferooter.textpieces/x86_64/stable
app/com.raggesilver.BlackBox/x86_64/stable
app/org.wezfurlong.wezterm/x86_64/stable

[zroug]

Okay, I noticed that it's not just memory usage, but also CPU usage. Again, I'm using BlackBox as an example. While it is open and just idling, flatpak-session-helper is constantly using between 1-2% of CPU time. It's not much, but since it never stops, it adds up. I think it has a big impact on battery life for example.

I made the following graph of CPU usage. At the beginning and the end BlackBox was closed, in the middle it was open. The impact on CPU while BlackBox was running is from flatpak-session-helper.

[RomanAverin]

I have the same problem and it started after BlackBox 0.14 update

[ashrude]

Wow, I'm using blackbox as well and didn't expect such a dramatic amount of resources to be freed when I closed it.

[raggesilver]

Hey, I think this is an issue with Black Box. Unless someone can confirm this happens with another program, I suggest closing this issue in favor of https://gitlab.gnome.org/raggesilver/blackbox/-/issues/322.

[zroug]

While I think it's not unlikely that there is a bug in BlackBox that causes this, I don't think the bug is only on the BlackBox side for the following reasons:

• The excessive resource consumption happens in the flatpak-session-helper and xdg-dbus-proxy processes.
• The enormous amount of memory used by flatpak-session-helper is not reclaimed when BlackBox is closed.

At least for the memory usage of these two processes, I think even a buggy application shouldn't be able to cause that much memory usage, especially if it's not reclaimed when the buggy application is closed. For CPU usage, of course, it's not so simple.

[qwertychouskie]

This also affects Mission Center: https://gitlab.com/mission-center-devs/mission-center/-/issues/61#note_1584564638

[joaoherrera]

While I think it's not unlikely that there is a bug in BlackBox that causes this, I don't think the bug is only on the BlackBox side for the following reasons:

• The excessive resource consumption happens in the flatpak-session-helper and xdg-dbus-proxy processes.
• The enormous amount of memory used by flatpak-session-helper is not reclaimed when BlackBox is closed.

At least for the memory usage of these two processes, I think even a buggy application shouldn't be able to cause that much memory usage, especially if it's not reclaimed when the buggy application is closed. For CPU usage, of course, it's not so simple.

You're right. I don't have BlackBox installed and I'm facing the same issues. In my case, it seems that the problem is related to the Telegram Desktop app. I installed it via flatpak.

[rstanuwijaya]

Can confirm also getting the same issue with BlackBox installed

[opqriu]

This problem happens all too often with Blackbox. Yesterday, today.

And years ago... It also happened when I was working with flatpak-Audacity on a low-end system. Back then, uninstalling flatpak-audacity and doing apt install audacity completely solved the problem.

[mardy]

I think this is fixed here: https://github.com/sailfishos/xdg-dbus-proxy/blob/master/rpm/0001-Fix-GVariant-reference-leaks.patch

[qwertychouskie]

It may very well be the fix. @spiiroin Is there any reason your patch (0001-Fix-GVariant-reference-leaks.patch) was never upstreamed?

[spiiroin]

Is there any reason your patch (0001-Fix-GVariant-reference-leaks.patch) was never upstreamed?

@qwertychouskie Nope, unless you count the usual: slipping through the cracks because this was a side track bug hunt while being busy with something else...

[sviperz]

So, what is a proper way to fix this issue now in the OS?

[swick]

@spiiroin do you mind opening a PR?

[matthiasclasen]

The fix was merged, closing this

[sviperz]

Assuming I have Ubuntu 24.04, how can I have this fix as soon as possible except building from source?

[LordManhattan]

It's still an issue. Looks like the source app is StreamController (Flatpak), and I have no idea why it's using this much RAM since it's never done it before (that I've noticed). Running Fedora WS 40.

[TingPing]

@LordManhattan Because this fix isn't in a release yet. I believe a new release will be coming very soon.