Public bug reported: # Compositor drift over a session (desktop drops 144→~55 fps), fixed by disabling the dock — and it is NOT a memory leak (RSS stays flat)
## TL;DR On a long-running GNOME/Wayland session, the desktop develops microstutter after a few **hours** (not days). Real presentation rate, measured with `mangohud vkcube`, drops from a fresh **144 fps (≈6.95 ms median frametime)** to **~55 fps (≈18 ms, spikes to 70 ms)**. `gnome- shell` does **not** grow in RAM — RSS stays flat (~224–401 MB) — so this is **not** the memory-leak family of reports (#2272, #1641, #44). It is CPU churn: the main thread climbs to 40–66% and the **KMS thread to 22–32% at an idle desktop**, pushing page-flips continuously. A controlled A/B at the same session age pins it on the dock: **dock ON → 54 fps, dock OFF → 144 fps**, even with a heavy background load running. ## Environment - Ubuntu 26.04, **GNOME Shell 50.1**, Wayland session - **ubuntu-dock v105** (Canonical's dash-to-dock fork; the un-disconnected-signal pattern looks shared with upstream) - Ryzen 7 5800X3D, Radeon RX 6950 XT (RADV NAVI21), Mesa 26.0.3, kernel 7.0.0 - Displays: DP-1 2560×1440@144 + VRR, DP-3 1680×1050@60 (also reproduces mono-screen) - No Blur-my-Shell (distinguishes this from the closed #2555). Other enabled extensions: ding, tiling-assistant, ubuntu-appindicators. Vitals was tested and **ruled out** (disabling it changed nothing). ## Symptom - After a few hours of session uptime, microstutter appears. In-app FPS counters can read 100+ while it *feels* like ~20. - **Measured presentation rate** (median frametime via `mangohud vkcube`): - fresh session: 6.95 ms → **144 fps** - aged session (~8–14 h): ~18 ms → **~55 fps**, frametime spikes up to 70 ms - At an **immobile** desktop, `gnome-shell` main thread sits at 40–66% and the **KMS thread at 22–32%**, continuously committing page-flips for a static scene. - Purged only by **logout/login** (which restarts gnome-shell). A full reboot is not needed. On Wayland there is no `Alt+F2 r`, so this is the only in-session remedy. ## This is NOT a memory leak `gnome-shell` RSS stays flat across every state: **224–401 MB** (fresh ≈ 291 MB; in the degraded 144→55 fps state it was 274–401 MB). The failure mode is accumulated work / re-firing callbacks on the compositor, not RAM growth — please don't file this under the existing leak issues. ## Journal evidence (accumulates over the boot) - thousands of: `g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failed` - flood of: `st_widget_get_theme_node called on the widget [...] which is not in the stage`, on **dock actors**: `DockDash`, `dashtodockContainer`, `DockShowAppsIcon` - also seen: `Cursor update failed: drmModeAtomicCommit: Invalid argument` (HW cursor plane rejected — possible KMS churn, secondary) Disabling the dock at runtime **stops the new spam immediately**, but does **not** drop CPU until gnome-shell restarts — consistent with already-leaked handlers surviving the unload. ## A/B test (the key evidence) — same machine, comparable session age | Session age | Dock | Background load | Median frametime | Presented fps | Frametime max | |---|---|---|---|---|---| | fresh boot | on | — | 6.95 ms | **144** | — | | ~8 h | **ON** | VM @ 501% CPU | 18.6 ms | 54 | 70 ms | | ~14 h | **ON** | idle | 18.2 ms | 55 | 66 ms | | ~9 h | **OFF** | VM @ 501% CPU | **6.95 ms** | **144** | 13.95 ms | The last row is the clincher: with the dock disabled, a 9-hour-old session holds fresh-boot 144 fps with tight frametimes — **even with a QEMU VM hammering 501% CPU**, which in the dock-ON case dragged presentation to 54 fps with 70 ms hitches. Removing the dock didn't just fix the idle drift, it made the compositor robust to scheduling perturbations again. ## Ruled out - Kernel / amdgpu: 0 GPU resets, 0 ring timeouts in the journal. - GPU clock bridging: `pp_dpm_sclk` reaches 2720 MHz, `gpu_busy` < 40% — not GPU-bound. - VRR / display config: reproduces with VRR on and mono-screen. - Multi-monitor: reproduces single-screen. - Vitals extension: disabling it changed nothing. ## How to reproduce / measure (gotchas) The snapshot script used to produce the table above is **attached** (`snap-bugreport.sh`), along with the raw per-state outputs (`snap_fresh.txt`, the aged-session captures, and `snap_nodock_*.txt`). Run it on a fresh session and again once the desktop feels laggy, then diff. - Measure the real **presentation** rate, not the app's internal FPS counter — they diverge here. `mangohud vkcube`, read the median frametime. **glxgears is useless on Wayland** (unfocused-window throttling gives garbage numbers). - Disable the dock with `gnome-extensions disable [email protected]`. Note: the global "Enable Extensions" toggle does **not** disable session-mode extensions like ubuntu-dock — it only touches per-user ones. Then logout/login. The disable persists across reboot. ## Hypothesis dash-to-dock connects global/stage signals (the handlers referenced in the spam) that aren't all disconnected when actors are destroyed/recreated during scene changes; they accumulate over a session and re-fire on every scene update, driving compositor CPU and continuous KMS page-flips → presentation drift. Consistent with the recurring "disconnect global signals" changelog entries and with #186 / #2406. ## What would help Whether the `g_object_get_qdata: G_IS_OBJECT failed` + `theme_node ... not in the stage` assertions on Dock actors point to a specific signal that isn't disconnected on actor destroy in v104/v105. The measurement script and raw snapshots are attached; happy to provide full journald excerpts or run targeted instrumentation on request. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: gnome-shell-ubuntu-extensions 50.26.04.7ubuntu ProcVersionSignature: Ubuntu 7.0.0-22.22-generic 7.0.0 Uname: Linux 7.0.0-22-generic x86_64 NonfreeKernelModules: zfs ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Jun 19 17:48:06 2026 InstallationDate: Installed on 2026-05-03 (47 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) PackageArchitecture: all ProcEnviron: LANG=fr_FR.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> SourcePackage: gnome-shell-ubuntu-extensions UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: gnome-shell-ubuntu-extensions (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug resolute wayland-session ** Attachment added: "Test file & raw reports" https://bugs.launchpad.net/bugs/2157653/+attachment/5978092/+files/dash-to-dock-drift-diagnostics.tar.gz -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2157653 Title: ubuntu-dock causes gnome-shell compositor drift (desktop 144→~55 fps) over a long session on Wayland — not a memory leak (RSS flat) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-ubuntu-extensions/+bug/2157653/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
