Public bug reported:
Filed separately because bug #2143073 comment #27 asks for a new bug for the
leak that mutter !5285 fixes ("we need someone to open a new bug about that
please"), repeated in comment #31. As far as I can tell nobody has opened one,
so this is it.
This is NOT the ShmemHugePages leak reported at the top of #2143073. There the
shmem is orphaned in pagecache with no process accounting for it. Here the
memory is attributed to gnome-shell's cgroup and the objects that grow are
dma-bufs listed in /sys/kernel/debug/dma_buf/bufinfo, released again when the
session leaves power saving. That matches upstream #4101 (detached_onscreens
never cleared during power saving).
WHY THIS IS ACTIONABLE NOW
--------------------------
The fix is no longer main-only. af0c9808 ("renderer/native: Don't keep around
detached onscreens in power saving") was merged into the gnome-50 stable branch
on 2026-09-15 via !5325, together with the two commits it depends on, 83c465ff
and c145106d. mutter 50.5 was tagged the same day and its NEWS lists !5285
under "Plugged leaks".
Resolute currently ships 50.1-0ubuntu2.2 (0ubuntu2.4 in -proposed), so the fix
is not present.
ENVIRONMENT
-----------
Ubuntu: 26.04.1 LTS (resolute)
Kernel: 7.0.0-31-generic
Session: GNOME on Wayland
gnome-shell: 50.1-0ubuntu1.2
libmutter-18-0 / mutter-common: 50.1-0ubuntu2.2
iGPU: Intel CometLake-H GT2 [8086:9bc4], i915
internal panel 3840x2160
dGPU: NVIDIA RTX 2060 Max-Q [10de:1f12], nvidia-driver-595
(proprietary) 595.91.07
two external 2560x1440, DP + HDMI
RAM: 64 GB, 8 GB swap
This is a hybrid Intel + NVIDIA setup running the proprietary driver. Upstream
#4101 has reproductions on amdgpu, i915 and xe, and comment #25 of #2143073
verified the fix on amdgpu. Neither covers this configuration.
STEPS TO REPRODUCE
------------------
1. GNOME Wayland session with at least one external display driven by the
secondary GPU.
2. Lock the screen and leave it locked for three minutes.
3. As root, watch /sys/kernel/debug/dma_buf/bufinfo and count the objects of
size 15728640 with exp_name "drm" (the file is root-only; as a normal user
it reads as empty).
4. Cross-check against the shmem field of memory.stat for the
[email protected] cgroup.
Expected: the counts stay at their pre-lock values while the session is
locked.
Actual: a new pair of buffers appears every ~3 seconds and nothing is released
until the session leaves power saving. Growth starts between 17 and about 100
seconds after locking (17 s, 74 s and 101 s in three logged runs) and is
reproducible in under two minutes in all five runs I logged.
MEASUREMENT
-----------
Sampling /sys/kernel/debug/dma_buf/bufinfo every ~6 s while locked, as
exporter:count/total_MB:
time shell shmem i915 drm i915 - drm
13:31:02 1049 MB 13/75 MB 3/45 MB 10
13:31:07 1357 MB 15/107 MB 5/75 MB 10
13:31:13 1755 MB 18/155 MB 8/120 MB 10
13:31:20 1793 MB 19/171 MB 9/135 MB 10
13:31:25 2075 MB 21/203 MB 11/165 MB 10
13:31:32 2345 MB 24/251 MB 14/210 MB 10
13:31:38 2495 MB 27/299 MB 17/255 MB 10
13:31:43 2769 MB 27/299 MB 17/255 MB 10
13:31:55 UNLOCK -> 14/91 MB 4/60 MB 10
"shell shmem" is the shmem field of memory.stat for the shell's cgroup; "drm"
is the exp_name as it appears in bufinfo, which on this machine is nvidia_drm.
The two exporters grow strictly 1:1: the i915 count minus the drm count stayed
constant in every sample of every run (10 here, 6 in two other runs; that
offset is just the non-scanout i915 buffers already present before locking).
Each leaked pair is one 15,728,640-byte buffer exported by "drm" -- that is
2560x1536x4, the scanout framebuffer of a 2560x1440 external output with the
height aligned -- plus one 16,777,216-byte (16 MiB) buffer exported by i915.
32.5 MB per pair, one pair every ~2.9 s, so about 11 MB/s of exported dma-buf.
The cgroup's shmem grows about 4x faster than that in the same window, 18 to
44 MB/s across five runs, so the exported buffers are the visible handle and
not the whole of the accounted memory. I have not chased down the rest.
Leaving power saving releases all of it at once: on unlock, and in one run on
reopening the lid while the session was still locked. That matches
clear_detached_onscreens only running from post_mode_set_updates.
gnome-shell's own open dma-buf fds stay flat throughout (16 in this run, 8 in
the others), so looking at /proc/<pid>/fd alone is misleading. The growth only
shows in the system-wide bufinfo list.
WHAT HAPPENED ON 2026-09-11 (on nvidia-driver-595-open)
-------------------------------------------------------
The one time this ran to completion was on 2026-09-11, two days before I
switched to the proprietary driver, so the numbers below come from
nvidia-driver-595-open. On that driver the memory was retained until the
compositor restarted rather than released on unlock. I am including it for the
magnitude, not as part of the measurement above.
The session was left locked and hit a global OOM:
[email protected]: Consumed 13min 30.581s CPU time over
1h 23min 25.473s wall clock time, 56.5G memory peak, 6.7G memory swap peak.
The kernel's own Mem-Info at that moment reports shmem:58914420kB (56.2 GiB)
with Free swap = 0kB. The OOM killer then took down 26 processes inside the
same second (00:21:45.896 to 00:21:45.972) -- the session bus, pipewire,
wireplumber, ibus and the portals among them -- and the session was gone 14
seconds later. The greeter afterwards crash-looped with a SIGSEGV in
libmutter-18 every 14 min 22 s until I rebooted, 8.5 hours later.
One caveat for anyone triaging from an OOM dump: this leak is invisible to RSS.
gnome-shell appears in the task dump with 168.7 MiB RSS while holding ~56 GiB,
and all 156 live processes together add up to 3.85 GiB. memory.current and
memory.stat on the cgroup are what show the real figure.
RULED OUT, WITH MEASUREMENTS
----------------------------
- nvidia-driver-595-open -> nvidia-driver-595 (proprietary): this removed the
drmModeAddFB2WithModifiers / gbm_bo_create failures for the secondary GPU
entirely, and changed the memory from retained-until-restart to
released-on-unlock, but the leak persisted. Two separate symptoms.
- prime-select on-demand -> nvidia: still leaks, pairs intact.
- Displays powered off (DPMS) while locked: still leaks, at the same rate
(one run).
- Lid closed, internal panel off, only externals active: still leaks, after
about 95 s.
- tmpfs sizing of /tmp and /dev/shm: unrelated, the memory has no file behind
it.
WORKAROUND
----------
The only thing that works here is disabling automatic screen lock:
gsettings set org.gnome.desktop.screensaver lock-enabled false
gsettings set org.gnome.desktop.session idle-delay 0
At the rates above, 64 GB plus 8 GB of swap goes in well under an hour; the one
time it actually ran to the end it took 57 minutes.
SRU
---
[Impact]
gnome-shell leaks a pair of scanout dma-bufs (15,728,640 B exported by drm plus
16,777,216 B exported by i915) roughly every 3 seconds while the session is
locked on a hybrid Intel + NVIDIA setup, until the machine hits a global OOM.
Fixed upstream by mutter !5285, backported to gnome-50 in !5325 and released in
mutter 50.5, listed in its NEWS under "Plugged leaks".
[Test Plan]
1. GNOME Wayland session, at least one external display on the secondary GPU.
2. Lock the screen; leave it locked three minutes.
3. As root, watch /sys/kernel/debug/dma_buf/bufinfo, counting objects of size
15728640 with exp_name "drm".
Broken: the count climbs by one every ~3 s and never drops while locked.
Fixed: the count stays at its pre-lock value.
4. Cross-check with the shmem field of memory.stat for
[email protected].
[Where problems could occur]
af0c9808 changes when detached onscreens are released, so a regression would
show up as flicker or a black output on the transition into or out of power
saving, or on monitor hotplug while blanked. It needs 83c465ff and c145106d;
c145106d itself fixes a crash on hotplug during power save, so taking af0c9808
alone would be worse than taking none of them.
[Other info]
Upstream issue: https://gitlab.gnome.org/GNOME/mutter/-/issues/4101
Fix in main: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/5285
gnome-50 backport: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/5325
Happy to test a build from -proposed on this hardware. Hybrid Intel + NVIDIA
proprietary with mixed-resolution outputs seems otherwise untested for this
fix, and I can reproduce the leak in under two minutes.
** Affects: mutter (Ubuntu)
Importance: Undecided
Status: New
** Affects: mutter (Ubuntu Resolute)
Importance: Undecided
Status: New
** Tags: amd64 gnome-shell-leak nvidia resolute wayland-session
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2167374
Title:
[nvidia] gnome-shell leaks scanout dma-bufs while locked (fixed in
mutter 50.5)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2167374/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
