possible memory leak with minimal Hyprland-only config

[WXZhao7]

Describe the bug

Waybar appears to grow memory steadily over time even with a very small configuration.

In this test run, CSS was disabled and only two built-in Hyprland modules were enabled:

• hyprland/workspaces
• hyprland/window

All center/right modules were commented out.

To reproduce

systemctl --user start waybar.service

{
  "layer": "top",
  "position": "top",
  "height": 34,
  "spacing": 0,
  "modules-left": [
    "hyprland/workspaces",
    "hyprland/window"
  ],
  "hyprland/workspaces": {
    "format": "{icon} {windows}",
    "format-window-separator": "",
    "sort-by": "id",
    "show-special": true,
    "special-visible-only": true,
    "on-scroll-up": "hyprctl dispatch 'hl.dsp.focus({ workspace = \"e+1\" })'",
    "on-scroll-down": "hyprctl dispatch 'hl.dsp.focus({ workspace = \"e-1\" })'",
    "format-icons": {
      "urgent": "",
      "special": "󰊠"
    },
    "workspace-taskbar": {
      "enable": true,
      "update-active-window": true,
      "format": "{icon}",
      "icon-size": 20,
      "on-click-window": "hyprctl dispatch 'hl.dsp.focus({ window = \"address:{address}\" })'"
    }
  },
  "hyprland/window": {
    "format": "{title}",
    "icon": true,
    "icon-size": 16,
    "max-length": 54,
    "separate-outputs": true,
    "rewrite": {
      "^\\s*$": "Desktop"
    }
  }
}

Expected behaviour
Waybar memory usage should remain mostly stable over time after startup.

Screenshots
If applicable, add screenshots to help explain the problem.

Environment

• Waybar: v0.15.0
• OS/kernel: Linux arch 7.1.2-arch3-1 x86_64
• Installed from Arch Linux official package: extra/waybar 0.15.0-2
• Compositor: Hyprland 0.55.4

Debug output

❯ waybar -l debug
[2026-07-06 19:15:32.807] [debug] Try expanding: $XDG_CONFIG_HOME/waybar/config
[2026-07-06 19:15:32.807] [debug] Try expanding: $XDG_CONFIG_HOME/waybar/config.jsonc
[2026-07-06 19:15:32.807] [debug] Found config file: /home/xxx/.config/waybar/config.jsonc
[2026-07-06 19:15:32.807] [info] Using configuration file /home/xxx/.config/waybar/config.jsonc
[2026-07-06 19:15:32.809] [debug] Try expanding: $XDG_CONFIG_HOME/waybar/style.css
[2026-07-06 19:15:32.809] [debug] Try expanding: $HOME/.config/waybar/style.css
[2026-07-06 19:15:32.809] [debug] Try expanding: $HOME/waybar/style.css
[2026-07-06 19:15:32.809] [debug] Try expanding: /etc/xdg/waybar/style.css
[2026-07-06 19:15:32.809] [debug] Found config file: /etc/xdg/waybar/style.css
[2026-07-06 19:15:32.809] [info] Using CSS file /etc/xdg/waybar/style.css
[2026-07-06 19:15:32.817] [debug] Output detection done: DP-2 (Xiaomi Corporation Mi Monitor )
[2026-07-06 19:15:32.818] [debug] window-rewrite is not defined or is not an object, using default rules.
[2026-07-06 19:15:32.818] [info] Hyprland IPC starting
[2026-07-06 19:15:32.818] [debug] Initializing workspaces
[2026-07-06 19:15:32.822] [debug] Initializing persistent workspaces
[2026-07-06 19:15:32.822] [info] Loading persistent workspaces from Hyprland workspace rules
[2026-07-06 19:15:32.822] [info] Registering for Hyprland's 'activewindowv2' events because 'update-active-window' is set to true.
[2026-07-06 19:15:32.831] [debug] GTK widget tree:
window#waybar.background.top.DP-2..mode-default.solo.firefox:dir(ltr)
  decoration:dir(ltr)
  box.horizontal:dir(ltr)
    box.horizontal.modules-left:dir(ltr)
      widget:dir(ltr)
        box#workspaces.horizontal.module:dir(ltr)
      widget:dir(ltr)
        box#window.horizontal.module:dir(ltr)
          image:dir(ltr)
          label:dir(ltr)
    box.horizontal.modules-center:dir(ltr)
    box.horizontal.modules-right:dir(ltr)

[2026-07-06 19:15:32.831] [debug] Creating workspace special:magic
[2026-07-06 19:15:32.832] [debug] Creating workspace 2
[2026-07-06 19:15:32.832] [debug] Creating workspace 1
[2026-07-06 19:15:32.832] [debug] Creating workspace 3
[2026-07-06 19:15:32.832] [debug] Creating workspace 4
[2026-07-06 19:15:32.832] [debug] Creating workspace 5
[2026-07-06 19:15:32.832] [debug] Creating workspace 6
[2026-07-06 19:15:32.835] [debug] Using 'desktop' search path prefix: 
[2026-07-06 19:15:32.835] [debug] Using 'desktop' search path prefix: /home/xxx/.local/share/
[2026-07-06 19:15:32.835] [debug] Using 'desktop' search path prefix: /usr/local/share/
[2026-07-06 19:15:32.835] [debug] Using 'desktop' search path prefix: /usr/share/
[2026-07-06 19:15:32.876] [debug] Received SIGCHLD in signalThread
[2026-07-06 19:15:32.880] [info] Bar configured (width: 1920, height: 34) for output: DP-2
[2026-07-06 19:15:32.885] [debug] hyprland IPC received openlayer>>waybar
[2026-07-06 19:16:02.864] [debug] Received SIGCHLD in signalThread
[2026-07-06 19:16:02.883] [debug] Received SIGCHLD in signalThread

Additional context
Anything else that might help.

[tomasz-feliksik]

Hi! I did some profiling on this and opened a PR that helps a lot on my setup: #5194.

Short version: with update-active-window, the hyprland/workspaces taskbar gets
rebuilt on every focus event, and each rebuilt widget seems to leave a
GtkCssStaticStyle behind in GTK. Skipping the rebuild when the taskbar content
hasn't actually changed took it from ~143 KB/focus-event down to ~0.7 KB here.

It doesn't fully solve the underlying GTK allocation — genuine changes (windows
opening/closing, titles updating) still cost a little — but it removes most of the
growth. Numbers and a backtrace are in the PR. Very open to feedback!

[tomasz-feliksik]

Update, and a correction to my earlier comment here.

My original numbers were wrong. I drove the benchmark with hyprctl dispatch focuswindow address:0x…, which under
Hyprland's Lua config mode (configType = "lua", 0.55+) is evaluated as Lua, prints a syntax error, does nothing, and
still exits 0. So it never changed focus. On master a no-op event costs the same as a real focus change (the taskbar
rebuilds either way), which is why the "before" figure looked sane and the "after" figure was measuring nothing. The
real improvement from that first commit is 4×, not 200×.

The root cause was also wrong. Profiling with heaptrack — and differencing each churn trace against an idle
control of the same duration — puts ~88% of the growth in GTK's icon theme, not in GtkCssStaticStyle (~8%).
updateTaskbar() re-resolves every window's icon on every rebuild; each GtkIconTheme lookup calls
ensure_valid_themes(), and GTK periodically reloads the whole theme inheritance chain without fully releasing the
previous one. Two independent leaks were sharing one symptom.

Fixed in #5194, now three commits: skip rebuilds when nothing rendered changed; cache resolved icon surfaces in
IconLoader (keyed by app-id + size + scale); and reuse the taskbar widgets in place instead of tearing down and
recreating the subtree. Measured on the same 200-focus-event run (3 monitors, all-outputs, update-active-window):

build	idle	per focus event
master 98b2a563	+988 kB / 20 s	143.0 KB
+ skip unchanged rebuilds	+0 kB	35.6 KB
+ cache icon surfaces	+0 kB	12.2 KB
+ reuse taskbar widgets	+0 kB	0.24 KB

0.24 KB/event is the same growth as running with workspace-taskbar: { enable: false } — the taskbar no longer
contributes. My bar used to reach ~600 MB of anonymous memory in 21 h; it now stays flat.

Three things that cost me time, in case they help anyone reproducing this:

• ps/RSS understates it badly. The leaked pages are cold, so zram/zswap compresses them out of RSS. Mine read
  ~180 MB RSS while actually holding 597 MB. Measure Anonymous + Swap from /proc/<pid>/smaps_rollup.
• heaptrack's "leaked" means still-allocated-at-exit, which counts GTK's one-time icon theme cache (several MB) as
  a leak. Always difference a churn trace against an equal-duration idle control.
• Don't trust a dispatcher's exit code. Count the activewindowv2 events your harness actually generated, off
  $XDG_RUNTIME_DIR/hypr/$HIS/.socket2.sock.

Workaround until this lands: workspace-taskbar: { enable: false }. No growth, and it roughly halves the bar's
baseline memory.