Adding a second failure mode for the same root cause, because it is not an OOM and it argues the Resolute task is more urgent than "memory grows" suggests.
On this machine the leak does not end in OOM. It ends in the compositor being unable to bring the panel up at all: after a lid-open resume the panel keeps the text console, a mouse cursor appears and tracks normally, and no desktop ever arrives. The cursor is the tell — it has its own KMS plane and needs a few hundred KiB, which still allocates, while the primary plane needs one contiguous full-panel framebuffer, which does not. Total free memory reads healthy the whole time and does not predict it, and bytes freed does not track recovery either. Measuring how many 3840x2400 XRGB8888 buffers (35.2 MiB each) a fresh GBM client can obtain: 781 MiB free 0-1 buffers desktop down 1035 MiB free 2 buffers after freeing 239 MiB, still down 1576 MiB free 19 buffers after a further 468 MiB, recovered The first release moved capacity not at all and the second took it from 2 to 19, so it is which blocks come back, not how many bytes. The session then returned on a VT switch with no restart, and gnome-shell went from 4482 MiB to 587 MiB across the reactivation, same pid — it had been holding all of it while the session sat inactive, which matches !5285 exactly. Two things follow that are worth having in the SRU case: * It does not self-recover. Reactivation allocates the new buffers before releasing the stale ones, so escaping needs headroom the shortage denies. Recovery means a text VT and killing GPU clients, or restarting gdm and losing the session. * Configurations with the panel on the dGPU hit it far earlier. In BIOS Discrete graphics mode every scanout comes from the 8 GiB card, so the leak competes directly with the framebuffer it will eventually block. A hybrid setup scanning out from the iGPU has system memory to absorb it. nvidia-smi memory.free is the wrong instrument here and will read fine while this is happening; what discriminates is whether a panel-sized scanout buffer can still be allocated at all. Environment: ThinkPad P16 Gen 3, Ubuntu 26.04, kernel 7.0.0-31-generic, libmutter-18-0 50.1-0ubuntu2.4, nvidia-driver-595 595.91.07 proprietary, panel 3840x2400 on the dGPU (BIOS Discrete), Wayland. 🤖 Pete Dietl -- 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: 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/mutter/+bug/2167374/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
