** Description changed: + Reported upstream too: https://github.com/micheleg/dash-to- + dock/issues/2613 + SUMMARY On GNOME 50.1 / Wayland the desktop presentation rate degrades from 144 fps to about 55 fps after a few hours of session uptime, while gnome- shell RSS stays flat (so this is not a memory leak). The drift correlates with the ubuntu-dock extension being enabled: with the dock disabled, a long session holds a fresh-boot 144 fps. Only a logout/login (gnome-shell restart) clears it. - ENVIRONMENT - Ubuntu 26.04, GNOME Shell 50.1, Wayland session - ubuntu-dock v105 (Canonical's dash-to-dock fork) - Ryzen 7 5800X3D, Radeon RX 6950 XT (RADV NAVI21), Mesa 26.0.3, kernel 7.0.0 - Displays: DP-1 2560x1440@144 + VRR, DP-3 1680x1050@60 (also reproduces mono-screen) - No Blur-my-Shell. Vitals was tested and ruled out (disabling it changed nothing). - + Ubuntu 26.04, GNOME Shell 50.1, Wayland session + ubuntu-dock v105 (Canonical's dash-to-dock fork) + Ryzen 7 5800X3D, Radeon RX 6950 XT (RADV NAVI21), Mesa 26.0.3, kernel 7.0.0 + Displays: DP-1 2560x1440@144 + VRR, DP-3 1680x1050@60 (also reproduces mono-screen) + No Blur-my-Shell. Vitals was tested and ruled out (disabling it changed nothing). SYMPTOM After a few hours of session uptime the desktop develops microstutter. In-app FPS counters can read 100+ while it feels like about 20. Real presentation rate, measured as the median frametime of "mangohud vkcube": - - fresh session: 6.95 ms -> 144 fps - - aged session (8 to 14 h): about 18 ms -> about 55 fps, frametime spikes up to 70 ms + - fresh session: 6.95 ms -> 144 fps + - aged session (8 to 14 h): about 18 ms -> about 55 fps, frametime spikes up to 70 ms At an idle, immobile desktop the gnome-shell main thread sits at 40-66% and the KMS thread at 22-32%, continuously committing page-flips for a static scene. The only in-session remedy is logout/login (which restarts gnome-shell). A full reboot is not needed. On Wayland there is no "Alt+F2 r". - THIS IS NOT A MEMORY LEAK gnome-shell RSS stays flat across every state: 224 to 401 MB (fresh is about 291 MB). The failure mode is CPU churn / accumulated callbacks on the compositor, not RAM growth. Please do not file this under the existing memory-leak reports. - JOURNAL EVIDENCE (accumulates over the boot) - - thousands of: g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failed - - a 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) + - thousands of: g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failed + - a 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 (same machine, comparable gnome-shell session age) - - fresh boot, dock on, no extra load : 6.95 ms median, 144 fps - - about 8 h, dock ON, VM at 501% CPU : 18.6 ms, 54 fps (frametime spikes to 70 ms) - - about 14 h, dock ON, idle : 18.2 ms, 55 fps - - about 9 h, dock OFF, VM at 501% CPU : 6.95 ms, 144 fps <-- the key result + - fresh boot, dock on, no extra load : 6.95 ms median, 144 fps + - about 8 h, dock ON, VM at 501% CPU : 18.6 ms, 54 fps (frametime spikes to 70 ms) + - about 14 h, dock ON, idle : 18.2 ms, 55 fps + - about 9 h, dock OFF, VM at 501% CPU : 6.95 ms, 144 fps <-- the key result With the dock disabled, a 9-hour session holds a fresh-boot 144 fps with tight frametimes, even with a QEMU VM pegged at 501% CPU, the very load that with the dock enabled dragged presentation down to 54 fps with 70 ms hitches. - RULED OUT - - Kernel / amdgpu: 0 GPU resets, 0 ring timeouts. - - GPU clock bridging: pp_dpm_sclk reaches 2720 MHz, gpu_busy below 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. - + - Kernel / amdgpu: 0 GPU resets, 0 ring timeouts. + - GPU clock bridging: pp_dpm_sclk reaches 2720 MHz, gpu_busy below 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 The capture script (session-snapshot.sh) and the raw per-state outputs are attached (dash-to-dock-drift-diagnostics.tar.gz). 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 meaningless numbers). - - Disable the dock with: gnome-extensions disable [email protected] (the global "Enable Extensions" toggle does not disable session-mode extensions like ubuntu-dock). Then logout/login. The disable persists across reboot. - + - 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 meaningless numbers). + - Disable the dock with: gnome-extensions disable [email protected] (the global "Enable Extensions" toggle does not disable session-mode extensions like ubuntu-dock). Then logout/login. The disable persists across reboot. HYPOTHESIS dash-to-dock connects global/stage signals (the handlers referenced in the spam) that are not all disconnected when actors are destroyed and recreated during scene changes. They accumulate over a session and re- fire on every scene update, driving compositor CPU and continuous KMS page-flips, hence the presentation drift. Consistent with the recurring "disconnect global signals" changelog entries upstream. - WHAT WOULD HELP Whether the G_IS_OBJECT and "theme_node ... not in the stage" assertions on Dock actors point to a specific signal that is not 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. Related upstream reports (different failure modes): micheleg/dash-to- dock issues 2555 (closed, confounded by Blur-my-Shell, different spam strings), 2272 / 1641 / 44 (RAM growth; ours is flat), 186 / 2406 (high CPU, no presentation-rate data).
-- 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
