Public bug reported:
Title: Shmem leak (~25 GB/h) leading to OOM when a DisplayPort monitor
repeatedly hotplugs while DPMS is off (regression in 50.1-0ubuntu2.4)
Package: mutter (libmutter-18-0 50.1-0ubuntu2.4), gnome-shell 50.1-0ubuntu1.3
Release: Ubuntu 26.04.1 LTS, kernel 7.0.0-38-generic
GPU: Intel Alder Lake-S GT1 UHD Graphics 730 [8086:4692], i915, Wayland session
RAM: 32 GB
[Impact]
After the screens blank (DPMS off), system Shmem grows ~25 GB/hour until
the kernel OOM-killer fires. The user session is lost (gnome-shell exits,
Chrome is OOM-killed), and afterwards the GDM greeter's gnome-shell leaks the
same way and is OOM-killed and restarted every ~1.7 h. The user returns to a
black screen or a login prompt with all work lost.
[Setup]
- DP-1: LG ULTRAGEAR
- HDMI-A-1: second monitor (primary)
- Screen blank after idle (org.gnome.desktop.session idle-delay)
[What happens]
1. Idle → DPMS off on both outputs.
2. ~16 s later the LG monitor on DP-1 drops HPD, then reconnects, and keeps
flapping connected/disconnected every 4–10 s (~470–520 state changes per
hour) for as long as the screens stay off. HDMI-A-1 stays stable.
This still happens with a new DP cable and with the monitor's
auto-standby / deep-sleep settings disabled.
3. On every flap gnome-shell logs:
meta_monitor_manager_get_logical_monitor_from_number: assertion '(unsigned
int) number < g_list_length (manager->logical_monitors)' failed
meta_workspace_get_work_area_for_monitor: assertion 'logical_monitor !=
NULL' failed
Can't update stage views actor unnamed [ClutterActor] is on because it
needs an allocation
4. /proc/meminfo Shmem rises from ~1.5 GB to ~29 GB (32 GB machine) → OOM.
The gnome-shell RSS itself stays around 130–330 MB.
If the screens are woken before the OOM, some of the memory (~10 GB
observed) is released.
[Regression]
This started right after the 2026-10-08 update
libmutter-18-0 50.1-0ubuntu2.2 → 50.1-0ubuntu2.4 (gnome-shell 1.2 → 1.3).
Before that, the same hardware and monitors worked fine. The 2.3/2.4 uploads
added the output-kms fallback-mode / refresh-rate-tolerance patches
(LP: #2163136), which run on every hotplug. I suspect they cause this, but I
have not confirmed it.
Right after the update, the logs were also spammed with
"Cursor update failed: drmModeAtomicCommit ...". Setting
MUTTER_DEBUG_DISABLE_HW_CURSORS=1 stopped that message completely
(0 occurrences over 40 h), but the Shmem leak and the OOMs still happened.
So the hardware cursor path is not the cause.
[Data, 2026-10-10 17:35 → 2026-10-12 08:58, with a single boot]
- DP-1 flaps: ~470–520 per hour while DPMS is off
- Peak Shmem per hour: 12 → 15 → 21 → 26 → 29 GB, then a sawtooth at ~29 GB
(OOM → greeter restart → leak again)
- Over 270 OOM kills, including the greeter's gnome-shell (UIDs 6058x/6059x) at
06:09, 07:50, 11:12, 12:53 (10-11) and 02:18 (10-12)
- User session 3 ended at 2026-10-10 21:47:09, right after Chrome was OOM-killed
(avail 0.4 GB, Shmem 20.5 GB)
- Attached excerpt: mutter-bug-hotplug-excerpt.log (the onset of the leak at
18:34 and the session loss at 21:4x)
[Expected]
A flapping connector shouldn't leak memory. Each hotplug should free
whatever it allocates.
[Workarounds]
Disabling screen blanking (so DPMS never turns off) avoids the trigger.
** Affects: mutter (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2170511
Title:
Shmem leak (~25 GB/h) leading to OOM when a DisplayPort monitor
repeatedly hotplugs while DPMS is off (regression in 50.1-0ubuntu2.4)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2170511/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
