** Description changed:
- # 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)
+ SUMMARY
- ## TL;DR
+ 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.
- 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
- ## 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; 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
+ 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.
+ After a few hours of session uptime the desktop develops microstutter. In-app
+ FPS counters can read 100+ while it feels like about 20.
- ## This is NOT a memory leak
+ 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
- `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.
+ 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.
- ## Journal evidence (accumulates over the boot)
+ 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".
- - 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.
+ THIS IS NOT A MEMORY LEAK
- ## A/B test (the key evidence) — same machine, comparable session age
+ 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.
- | 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.
+ JOURNAL EVIDENCE (accumulates over the boot)
- ## Ruled out
+ - 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)
- - 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.
+ 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.
- ## 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.
+ A/B TEST (same machine, comparable gnome-shell session age)
- - 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.
+ - 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
- ## Hypothesis
+ 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.
- 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
+ RULED OUT
- 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.
+ - 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.
- 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)
+
+ 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.
+
+
+ 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).
** Description changed:
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.
+ 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).
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.
+ 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":
+ 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
- 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.
+ 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".
+ 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.
+ 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)
+ - 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.
+ 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
- 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.
+ 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.
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.
+ 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.
+ - 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.
+ - 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.
+ 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.
+ 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).
+ 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
