Public bug reported:
[ Impact ]
On Ubuntu 24.04, repeated FileChooser portal requests cause
xdg-desktop-portal-gnome to retain a substantial amount of memory after
each request.
This is reproducible with the xdg-desktop-portal-gnome 46.2 implementation
currently shipped in Noble.
On the tested system, opening and cancelling 20 FileChooser requests
produced:
startup: 123.40 MiB
after request 10: 365.51 MiB
after request 20: 560.69 MiB
after 120 seconds: 560.50 MiB
This corresponds to approximately 19-20 MiB retained per request. The
memory does not return after the dialogs are closed or after a 120-second
settling period.
During long desktop sessions this can leave xdg-desktop-portal-gnome using
hundreds of MiB of resident memory and eventually swap, causing noticeable
desktop and FileChooser stuttering.
The leak is caused by the lifetime handling of the two GTK toplevel windows
created for a FileChooser request.
The chooser dialog receives an additional reference through
g_object_ref_sink(), while the hidden GTK parent window is not destroyed
when the request finishes.
The proposed fix keeps non-owning pointers to the chooser dialog and hidden
parent and destroys both GTK toplevels when the request closes.
With the proposed patch, the same 20-request test produced:
startup: 123.60 MiB
after request 10: 193.31 MiB
after request 20: 195.93 MiB
after 30 seconds: 195.89 MiB
after 120 seconds: 195.89 MiB
Growth between requests 10 and 20 is only 2.62 MiB total, followed by a
stable settling period. All 20 requests completed without timeouts.
[ Test Plan ]
Tested environment:
Ubuntu: 24.04 Noble
xdg-desktop-portal-gnome: 46.2-0ubuntu1
xdg-desktop-portal: 1.18.4
GTK: 4.14.5
GNOME: 46
session: X11
A reproducer and the raw measurements are attached to this bug.
1. Start with a fresh xdg-desktop-portal-gnome process.
systemctl --user restart xdg-desktop-portal-gnome.service
2. Record the initial RSS of the process.
3. Open and cancel 20 FileChooser portal requests, recording the RSS after
each completed request.
4. Record RSS again after 30 seconds and after 120 seconds.
With the current Noble package, RSS grows approximately linearly during
the test and remains near 560 MiB after the settling period.
5. Install a package containing the proposed patch and repeat exactly the
same test.
Expected result with the proposed update:
* FileChooser requests continue to open, cancel, and return normally.
* Memory rises during initial GTK/FileChooser warm-up but then plateaus.
* There is no approximately 19-20 MiB increase for every subsequent
FileChooser request.
* RSS remains approximately stable during the 30-second and 120-second
settling measurements.
Functional regression checks should additionally verify:
* Open File can be opened and cancelled.
* Open File can successfully select a file.
* Save File can be opened and cancelled.
* Save File can successfully select a destination.
* Repeated dialogs continue to work.
* The dialog remains correctly parented/modal and focus behaviour is
unchanged.
[ Where problems could occur ]
The change affects lifetime management of the GtkWindow objects used by
the FileChooser portal.
If the dialog were destroyed too early, possible regressions would include
a FileChooser closing before a response is returned, failed OpenFile or
SaveFile requests, use-after-free/crashes, or errors when cancelling a
request.
If the hidden parent lifetime were handled incorrectly, regressions could
appear in transient-window parenting, modality, focus, window stacking, or
dialog behaviour on X11 or Wayland.
For this reason the verification should cover successful and cancelled
OpenFile/SaveFile requests, repeated requests, and normal dialog parenting
in addition to the memory measurement.
The patch intentionally does not change the FileChooser behaviour or
external-window parenting mechanism. It only makes the lifetime of the two
GTK toplevels created for each request explicit.
[ Other Info ]
This is distinct from LP: #2085698.
LP: #2085698 was ultimately attributed to a GTK4 FileChooser gesture leak
and fixed in GTK4. The system used for this reproduction already contains
the Noble GTK update containing that fix, but this separate per-request
lifetime leak remains reproducible.
Current upstream xdg-desktop-portal-gnome main no longer contains this
FileChooser implementation; newer GNOME releases delegate the FileChooser
portal to Nautilus. Consequently there is no equivalent change to apply to
current upstream main.
The affected implementation remains in Ubuntu 24.04's GNOME 46
xdg-desktop-portal-gnome package, so this fix is being proposed as a
Noble-specific stable-release backport.
The attached evidence archive contains the reproducer, raw baseline and
patched measurements, methodology, reproduction instructions and
checksums.
** Affects: xdg-desktop-portal-gnome (Ubuntu)
Importance: Undecided
Status: New
** Patch added: "Proposed fix for Noble"
https://bugs.launchpad.net/bugs/2166815/+attachment/5998693/+files/xdg-desktop-portal-gnome-noble-filechooser-toplevel-leak.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2166815
Title:
[Noble] FileChooser portal retains GTK toplevel windows after each
request
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal-gnome/+bug/2166815/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
