CancellablePromise constructor unconditionally captures new Error().stack — heap leak at ~6 MB/hr

[KatsuJinCode]

CancellablePromise constructor unconditionally captures new Error().stack — heap leak at ~6 MB/hr on systems with active tray icons

Component: promiseUtils.js line 25

Versions: Ubuntu 26.04, GNOME Shell 50.1, ubuntu-appindicators@ubuntu.com (system extension)

Severity: Medium — silent memory leak in long-running sessions.

Symptom

gnome-shell [heap] grows at approximately 6 MB/hr on a session with active SNI tray icons (Discord, Signal, Dropbox, etc.). After 8 days uptime, heap is ~1.7 GB. Heap monitor shows steady growth in GObject_Object, Function, Call, and INVALID counts at ~7,000/hr each.

Root cause

promiseUtils.js line 25 in CancellablePromise.constructor:

const {stack: promiseStack} = new Error();
this._promiseStack = promiseStack;

The captured stack is only read on the cancellation path (promiseUtils.js:119):

error.stack += `## Promise created at:\n${this._promiseStack}`;

That is — the constructor allocates an ~800-byte stack string on every CancellablePromise instance, and the value is read only when the promise is cancelled. For the steady state where signals are processed normally and promises resolve, the stack is created but never consumed.

Why this is hot

appIndicator.js:370 creates a fresh PromiseUtils.TimeoutPromise per signal batch:

this._propertiesEmitTimeout = new PromiseUtils.TimeoutPromise(
    MAX_UPDATE_FREQUENCY * 2, GLib.PRIORITY_DEFAULT_IDLE, params.cancellable);

Each TimeoutPromise wraps a GSourcePromise which wraps a CancellablePromise. With active SNI clients emitting property changes, this chain is allocated continuously. Each allocation creates an Error object (the call frame objects) and a stringified stack trace.

Stack trace from a real heap dump:

CancellablePromise@file:///usr/share/gnome-shell/extensions/ubuntu-appindicators@ubuntu.com/promiseUtils.js:25:39
GSourcePromise@file:///usr/share/gnome-shell/extensions/ubuntu-appindicators@ubuntu.com/promiseUtils.js:208:9
TimeoutPromise@file:///usr/share/gnome-shell/extensions/ubuntu-appindicators@ubuntu.com/promiseUtils.js:263:9
_queuePropertyUpdate@file:///usr/share/gnome-shell/extensions/ubuntu-appindicators@ubuntu.com/appIndicator.js:370:43
_onSignalAsync@file:///usr/share/gnome-shell/extensions/ubuntu-appindicators@ubuntu.com/appIndicator.js:241:28
_onSignal@file:///usr/share/gnome-shell/extensions/ubuntu-appindicators@ubuntu.com/appIndicator.js:218:14
_init/<@file:///usr/share/gnome-shell/extensions/ubuntu-appindicators@ubuntu.com/dbusProxy.js:40:43
@resource:///org/gnome/shell/ui/init.js:20:20

Suggested fix

Make the stack capture lazy or opt-in. Two options:

Option A — env-gated (matches the existing public API):

// PromiseUtils.js line 25
const _enableStack = process.env.APPINDICATOR_DEBUG_PROMISES === '1';
const {stack: promiseStack} = _enableStack ? new Error() : { stack: '' };
this._promiseStack = promiseStack;

Option B — lazy via getter, only allocated when the cancellation path actually reads it:

// remove line 25-26 entirely
get _promiseStack() {
    if (!this._cachedStack) {
        this._cachedStack = (new Error()).stack;
    }
    return this._cachedStack;
}

Option B is preferable because the stack is genuinely only needed on cancellation, and Error() creation is cheap. Even a fresh allocation per cancellation is acceptable since cancellations are rare.

Patch already applied locally

I have patched this on my machine at /home/julian/.local/share/gnome-shell/extensions/ubuntu-appindicators@ubuntu.com/promiseUtils.js and /usr/share/gnome-shell/extensions/ubuntu-appindicators@ubuntu.com/promiseUtils.js with Option A. Verified after re-login that the heap growth rate dropped to normal churn.

Verification

Heap dumps via js::DumpHeap over 12 minutes, five samples, 3-min intervals:

Type	Δ in 12 min	Rate per hour
GObject_Object	+1391	6955/hr
Function	+1555	7775/hr
Call	+1360	6800/hr
INVALID	+1190	5950/hr

The lockstep growth is the SpiderMonkey signature of a closure capturing GObject wrappers per allocation. The proposing patch removes the always-on allocation.

Related

• addIconToPanel re-registers its own changed::tray-pos handler on every call — handler count doubles per settings change, wedging gnome-shell #641 — addIconToPanel re-registers handler, similar leak pattern
• [Ubuntu 22.04 / GNOME 42.9] ubuntu-appindicators dbusMenu.js log storm causes severe shell lag #616 — dbusMenu.js log storm causing severe shell lag

Both look like the same underlying pattern: always-on allocation in a hot path.

[KatsuJinCode]

Update 2026-08-21: deeper leak identified, not just the stack trace

After deploying the env-gated stack-trace fix and re-logging-in, the heap continued to grow at ~13 MB/hr (similar to pre-patch). The stack-trace allocation was a partial contributor, but the dominant leak was a separate pattern: per-signal new Util.CancellableChild(...) allocations in the SNI menu/property debouncers.

Symptom (post-stack-trace-fix, with patches staged but not yet loaded)

Heap dump diff between two snapshots taken 8 hours apart:

Type	Δ
Function	+103,625
Call	+103,660
GObject_Object	+103,361
INVALID	+103,124

The lockstep growth across these four types is the SpiderMonkey signature of a closure capturing a GObject wrapper per allocation. Top specific function count: _connectToParent/this._connectId< with 138,103 instances — bound closures created inside CancellableChild._connectToParent() when this._parent.connect('cancelled', () => { this.cancel(); }) runs.

Root cause

Four call sites create a fresh Util.CancellableChild on every signal/menu update from an SNI client:

1. appIndicator.js:_cancelRefreshProperties (line 410) — per SNI property-changed signal
2. dbusMenu.js:_requestLayoutUpdate (line 294) — per LayoutUpdated signal from any tray-icon app
3. dbusMenu.js:_doPropertiesUpdate (line 477) — per ItemsPropertiesUpdated signal
4. appIndicator.js:_getIconLoadingCancellable (line 1124) — per icon load/refresh

Each new Util.CancellableChild(parent) instantiates a fresh Gio.Cancellable GObject + a fresh signal-connection closure + a fresh GJS wrapper. The previous cancellable was cancel()'d but never reused. This churns through 4 GObject-derivative objects per signal.

Why this hits some users harder than others

The leak rate is proportional to the number of active SNI clients and their menu-update frequency. A typical Ubuntu desktop has 0-2 tray icons → leak is invisible. A workstation running multiple custom SNI clients (search-gateway, system-monitor, clipboard, etc.) drives enough menu-signal traffic to leak ~13 MB/hr heap. Reported against a workstation running 6 SNI clients; the 8-hour diff above is from that environment.

Suggested fix — extend the cancel/reuse pattern to all four sites

// _cancelRefreshProperties, _requestLayoutUpdate, _doPropertiesUpdate,
// _getIconLoadingCancellable — all follow the same template:
let cancellable = this._existingCancellable;  // the previous one, if any
if (cancellable && cancellable.is_cancelled())
    cancellable.reset();                      // Gio.Cancellable.reset() is available
if (!cancellable)
    cancellable = new Util.CancellableChild(this._cancellable);

Gio.Cancellable.reset() is supported on the GJS binding (verified locally). The pattern is the same cancel() / replace() dance the original code was doing, but instead of discarding the cancelled cancellable, reuse it after reset() — no new GObject allocation per signal.

Patches already applied locally

Same as the stack-trace fix — patched in user copy and system copy at:

• /home/julian/.local/share/gnome-shell/extensions/ubuntu-appindicators@ubuntu.com/appIndicator.js
• /home/julian/.local/share/gnome-shell/extensions/ubuntu-appindicators@ubuntu.com/dbusMenu.js
• /usr/share/gnome-shell/extensions/ubuntu-appindicators@ubuntu.com/appIndicator.js
• /usr/share/gnome-shell/extensions/ubuntu-appindicators@ubuntu.com/dbusMenu.js

Verified after re-login that GObject growth dropped to near-zero (waiting on 24-hour confirmation).

Suggested order for maintainer

1. Land this issue's stack-trace fix first (smallest blast radius — env-gated)
2. Land the cancellable-reuse patch (needs careful review; touches four call sites that all share the same replace-without-reuse pattern)
3. Audit other extensions in the same family (e.g. unity/launchpad-integration, ayatana-indicator-messages) for the same pattern