Webview renderer leaks ~25 MB/hour while idle

[nedtwigg]

Summary

The Dormouse webview renderer leaks roughly 25 MB/hour on a completely idle terminal. Growth tracks wall-clock time, not terminal output. Measured over a 9.6-hour idle window the webview grew 73 MB → 322 MB (4.4x) while only 2.5 MB of PTY output flowed through the whole session.

The pty-host process is unaffected and behaves well (see "What is not leaking" below).

Evidence

Sampled PSS every 30s from /proc/<pid>/smaps_rollup, with terminal output volume taken from the pty-host's /proc/<pid>/io rchar counter as an activity proxy.

Overnight run, machine idle:

23:30    67 MB      04:00   187 MB
00:30    94         06:00   240
01:30   120         07:30   279
02:30   146         08:30   306
03:30   173         09:03   322   <- peak

These are 30-minute minima, not means. The floor rose monotonically across all nineteen buckets with no reversal — memory is never reclaimed. A sawtooth (cache/scrollback churn) would show a flat floor with oscillating peaks.

Reproduced across three separate renderer processes, including two spanning an active workday of builds and one spanning a dead-quiet night:

instance	duration	range	rate
A	1.0 h (active)	77.6 → 108.2 MB	+19.7 MB/h
B	7.3 h (active)	70.1 → 273.0 MB	+27.0 MB/h
C	9.6 h (idle)	70.4 → 322.3 MB	+25.1 MB/h

Near-identical slope under a full workday of terminal activity and under an idle night is the key result: output volume is not the driver.

Control: the VS Code main window renderer, same Electron, same night, same host: +6.55 MB/h — ~4x slower. So this is not baseline Electron drift.

Each instance starts around 70 MB, so the leak appears to begin at webview creation.

What is not leaking

The pty-host process is a clean bill of health, worth recording so it can be ruled out:

• +0.49 MB/hour over a 7.3-hour continuous lifetime, and it reclaims — hourly means rose 27.8 → 34.9 MB then fell back to 32.4 MB and held. Bounded sawtooth.
• Process lifecycle is clean: exactly one pty-host at a time, no orphans across several extension-host restarts, and child count tracked open panes with no churn or accumulation.

Impact

At 25 MB/h the webview passes ~600 MB in a day and ~1 GB in under two, with nobody typing.

This compounds a second issue on memory-constrained machines: processes spawned from a Dormouse terminal inherit VS Code's cgroup (app-code-*.scope), so on a systemd-oomd system the leak is charged to the editor's scope and counts toward the kill decision. On a 6.6 GB laptop this contributed to systemd-oomd killing the whole VS Code scope. An editor left open over a weekend could reach the threshold from the leak alone.

Suspects

Idle growth on a clock points away from scrollback and toward something on a timer. Ranked by fit, unverified:

1. lib/src/lib/quiesce-detector.ts / lib/src/lib/alert-manager.ts — the Activity layer is timer-driven by design (docs/specs/alert.md); an interval appending without eviction matches this signature.
2. lib/src/lib/terminal-state-store.ts — command runs / title candidates, if they accrue per tick rather than per command.
3. lib/src/lib/session-dirty.ts — its own comment notes state changes "even with no user activity", which is exactly the observed condition.

Reproduction

1. Open a Dormouse panel in VS Code with one idle terminal. Do not type.
2. Sample the webview renderer's PSS every 30s:
   awk '/^Pss:/{s+=$2} END{print s}' /proc/<renderer-pid>/smaps_rollup
   The webview is the VS Code renderer starting at ~70 MB (the main window renderer starts at ~200 MB+).
3. Growth of ~25 MB/hour appears within an hour and stays linear.

Fastest path to a culprit: Developer: Open Webview Developer Tools, take heap snapshots an hour apart and compare retained sizes. At this rate the delta should name the retaining object directly.

Environment

• Dormouse extension 1.1.0
• VS Code 1.135.0 (Electron 42.8.1), Wayland
• Ubuntu 26.04.1 LTS, kernel 7.0.0-30-generic, x64
• 6.6 GB RAM, systemd-oomd active

[dormouse-bot]

I can't reproduce a multi-hour renderer leak from CI, so this is a static audit rather than a fix. The headline: all three ranked suspects are bounded — I don't think any of them is the driver, and chasing them first would burn the heap-snapshot window.

• quiesce-detector.ts holds a fixed set of scalar fields and five setTimeout handles, each cleared before it is re-armed, and every timer is armed from onData — an idle Session arms none. Nothing appends.
• terminal-state-store.ts accumulates in exactly one place, and it's capped: promptOutputBuffers is rewritten as .slice(-1024) on every write (terminal-state-store.ts#L228). titleCandidates is keyed by source, not appended. Every other Map there is keyed by pane id and deleted in removeTerminalPaneState.
• session-dirty.ts is two integers. Its "state changes even with no user activity" comment is about the first heartbeat after boot, not a standing condition: the 30 s heartbeat is dirty-gated (use-session-persistence.ts#L162) and saveSession resolves, so completeSave runs and an idle session's heartbeat is a no-op after the first write.

The more useful thing I can offer is a discriminator to run before the hour-apart snapshots, because it decides which half of the process you're hunting in. Compare performance.memory.usedJSHeapSize against the PSS delta. If the JS heap is flat while PSS climbs ~25 MB/h, the growth is native — canvas/WebGL/DOM — and a JS heap snapshot diff will name nothing, which would burn the window your report correctly identifies as the fastest path.

That split matters here specifically because the largest native-memory difference between this renderer and your VS Code control is the WebGL renderer, and there is already a one-flag A/B for it: cfg.terminal.webglRenderer (cfg.ts#L42), whose own comment documents flipping it as the way to A/B the renderer. Setting it false and repeating one idle night isolates @xterm/addon-webgl from everything else in one run. You can confirm which path a pane actually took from the data-renderer attribute on its host element (webgl or dom).

What else I audited and ruled out

Audited at 2d4edb824138fb730103b8fb6d211372d0237279. Looking specifically for something that allocates on a wall clock and is never reclaimed, since that is the signature your data establishes.

Every periodic timer in the webview, and why none of them fires on an idle terminal-only pane:

site	cadence	idle behavior
use-session-persistence.ts:161	30 s	dirty-gated; no-op once the first save completes
host-status-store.ts:132	2 s	only while the Settings dialog is mounted (listeners.size === 1 arms it, last unsubscribe clears it)
use-dev-server-ports.ts	4 s	only while a browser surface has an unmatched wanted port; a terminal-only Wall returns 'idle' and stops
use-dor-control.ts:252, terminal-lifecycle.ts:412	100 ms	bounded one-shots during dor ensure --restart / command launch; both clearInterval on resolve and on timeout

Neither host process has a timer that posts to the webview — grep setInterval over vscode-ext/src and lib/src/host returns nothing (the one hit under standalone/sidecar/main.js is the Tauri parent-PID watchdog, not this host).

Other things that looked like candidates and aren't:

• The Lath rAF animation loop terminates — settledAt goes true once now >= start + duration for every segment (animator.ts#L268), and pump only reschedules while unsettled. It is not a standing 60 fps loop.
• startThemeObserver is start-guarded (terminal-theme.ts#L80), so N panes don't mean N MutationObservers. useDynamicPalette writes document.body.style, which wakes both that observer and its own, but both converge in one extra pass on a value compare rather than oscillating.
• The requestResponse reply listeners in vscode-adapter.ts detach on their own timeout, and the docstring shows the "promise that never settles keeps its .then closures alive" case was already considered.
• agent-browser-connection.ts debugEvents is a ring buffer (DEBUG_RING_LIMIT).
• AlertManager.removed is an unbounded tombstone Set of killed pane ids, only cleared on reset — real, but it grows per pane kill, not per unit time, and it holds id strings. Wrong shape and wrong order of magnitude for 25 MB/h; noting it only so it can be ruled out rather than rediscovered.

The one wall-clock allocator I did find, offered as a lead rather than a finding. cursorBlink is on (cfg.ts#L35), and xterm's onRender calls bumpRenderTick() (terminal-lifecycle.ts#L292), which fans out to a global listener set (mouse-selection.ts#L304) — so any one pane's render re-renders every pane's SelectionOverlay and SelectionPopup via useSyncExternalStore. That's O(N²) React work on a clock, and it is the only thing I found that allocates steadily with no terminal output. Two reasons I'm not calling it the cause: both components bail to null immediately when there's no selection, so the per-tick garbage is small and should be collectable; and xterm pauses CursorBlinkStateManager when the terminal is blurred, which an overnight idle window most likely was. If the JS-heap-vs-PSS check above comes back "JS heap is growing", this is where I'd look first.