Public bug reported:
Summary
ShellUserVerifier.destroy() disposes the upstream this._settings but never
disposes or disconnects Ubuntu's added this._ubuntuSettings. Because
ShellUserVerifier extends Signals.EventEmitter — a plain JS class, not a
GObject — the connectObject(..., this) on _ubuntuSettings has no destroy signal
to hook and therefore never auto-disconnects.
Destroyed verifiers stay subscribed forever. Every change to
com.ubuntu.login-screen then fires a handler on each stranded verifier,
which dereferences the already-nulled this._settings and throws.
This is in Ubuntu-specific code, not upstream: the schema is
com.ubuntu.login-screen, the imports are ./authd.js /
Authd.AuthdSwitchableHandler, and the changelog carries these under
d/p/ubuntu-authd.
Root cause
In js/gdm/util.js, the ShellUserVerifier constructor:
this._settings = new Gio.Settings({schema_id: LOGIN_SCREEN_SCHEMA});
this._settings.connect('changed', () => this._onSettingsChanged());
this._ubuntuSettings = new Gio.Settings({schema_id:
UBUNTU_LOGIN_SCREEN_SCHEMA});
this._ubuntuSettings.connectObject('changed', () => this._onSettingsChanged(),
this);
and destroy():
destroy() {
this.cancel();
this._settings.run_dispose(); // upstream settings: disposed
this._settings = null;
// _ubuntuSettings: NEVER disposed
this._smartcardManager?.disconnectObject(this);
this._smartcardManager = null;
...
}
run_dispose() on _settings severs its connections, so the upstream handler is
fine. _ubuntuSettings is left live.
Observable symptom
JS ERROR: TypeError: this._settings is null
_updateEnabledServices@resource:///org/gnome/shell/gdm/util.js:851:13
_onSettingsChanged@resource:///org/gnome/shell/gdm/util.js:844:14
ShellUserVerifier/<@resource:///org/gnome/shell/gdm/util.js:184:66
@resource:///org/gnome/shell/ui/init.js:21:20
Note the frame is util.js:184, which is the _ubuntuSettings line — the upstream
_settings connection on line 182 does not appear, exactly as expected given
run_dispose().
_updateEnabledServices() (line 851) then does
this._settings.get_boolean(FINGERPRINT_AUTHENTICATION_KEY) on a null.
Evidence it accumulates
The error count grows monotonically with the number of stranded verifiers. From
one long-running session's journal:
30 2026-09-14
40 2026-09-15
90 2026-09-16
50 2026-09-17
60 2026-09-18
65 2026-09-19
68 2026-09-20
70 2026-09-21
70 2026-09-22
70 2026-09-23
Each settings change multiplies out across every leaked verifier.
Steps to reproduce
Lock and unlock the session several times.
Touch the Ubuntu login-screen schema, e.g. gsettings set
com.ubuntu.login-screen enable-authd-authentication false (then set it back).
journalctl _COMM=gnome-shell -b | grep "this._settings is null" — one error per
stranded verifier, growing with the number of lock cycles.
Proposed fix
Mirror the existing _smartcardManager cleanup in the same method:
this._settings.run_dispose();
this._settings = null;
+this._ubuntuSettings?.disconnectObject(this);
+
this._smartcardManager?.disconnectObject(this);
this._smartcardManager = null;
disconnectObject(this) is preferable to nulling the field, because
_ubuntuSettings is still read at util.js:899
(this._ubuntuSettings.get_boolean(UBUNTU_AUTHD_AUTHENTICATION_KEY)).
Verification
Applied locally via G_RESOURCE_OVERLAYS on 46.0. Before: ~70 errors/day and
climbing. After, across 9 lock/unlock cycles: 0 occurrences of this._settings
is null.
Description: Ubuntu 24.04.5 LTS
Release: 24.04
** Affects: gnome-shell (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-shell in Ubuntu.
https://bugs.launchpad.net/bugs/2168453
Title:
ShellUserVerifier leaks its _ubuntuSettings handler, spamming
"TypeError: this._settings is null"
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/2168453/+subscriptions
--
desktop-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
