I think I can add a mechanism for this bug, from detailed instrumentation of what appears to be the same leak on similar hardware. (Cross-refs: my i915 report LP #2148793, and LP #2156739 where most of the evidence below is accumulating.)
Setup: ThinkPad T16 Gen 4, Arrow Lake-U (8086:7D41), Ubuntu 24.04, kernel 6.17.0-1028-oem, mutter 46.2-1ubuntu0.24.04.15, GNOME 46 Wayland, clamshell mode (lid closed), single external HDMI 3840x2160@60. Note: my GPU currently runs the xe driver (force-probed to escape the i915 shmem variant in LP #2148793). On xe the leaked memory shows up as exported DMA-BUF/TTM objects instead of Shmem/ShmemHugePages, but the trigger and growth pattern are identical, so I believe these are the same Mutter-level bug with the memory accounted differently by the two drivers. That would explain why "no single process accounts for the leaked pages" here: they are GPU buffer objects, only visible via /proc/<gnome-shell-pid>/fdinfo (drm-total-gtt, and fds with exp_name/size fields) or /sys/kernel/debug/dma_buf/bufinfo. Mechanism, captured with dbus-monitor while the display was in DPMS-off: 1. While the display is powered off, Mutter (gnome-shell) emits MonitorsChanged on org.gnome.Mutter.DisplayConfig in PAIRS every ~8.5 seconds, continuously, for the entire display-off period. (The portal, gsd-xsettings and gsd-power each respond with GetCurrentState/GetResources every cycle; xdg-desktop-portal-gnome also logs "Monitor 'Built-in display' has no configuration which is-current!" each cycle in my clamshell config.) 2. Each cycle strands ~2 framebuffer-sized buffers (32 MB each at 4K) in gnome-shell: exported DMA-BUF fd count grows ~12/min, ~0.5 GB/min at 4K. In one 45-minute locked period I measured fds 12 -> 396 (~12.3 GB) before a global OOM killed the session. 3. The buffers are NEVER released when the display wakes — only a gnome- shell restart frees them. At OOM time ~30 GB of 31.5 GB RAM was unaccounted (anon ~0, swap ~90% free), so the OOM killer shoots unrelated processes. A co-trigger seems to be required: display-off on an otherwise quiet system did not leak in my tests. In my case the event source is audio streaming over HDMI to the monitor's speakers during DPMS-off; the "monitor input autodetection" / hourly disconnect- reconnect observations in this bug look like another flavor of the same thing — something generating repeated connector/hotplug events while the display is in power-save, each of which Mutter answers with a reconfiguration that allocates buffers it never frees. The .12-vs-.13 finding in this bug is very interesting in that light: 46.2-1ubuntu0.24.04.13 is the SRU that backported the DPMS/hotplug behavior changes from LP #1971434 (Mutter MR !4209 hotplug hysteresis, plus related monitor-manager changes). My .15 exhibits the leak; the report that .12 was clean for 20 days points squarely at that changeset as the regression window. LP #2146851 independently reports that monitors started truly powering off (DPMS) rather than blanking after the same .13 update, with daily OOMs while locked — on a 6.8 generic kernel, so this does not appear to be specific to the 6.17-oem kernel series. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/2143073 Title: ShmemHugePages leak during GNOME lock screen on 6.17.0-1012-oem causes OOM To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/2143073/+subscriptions -- desktop-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
