The root cause is in mate-notification-daemon, not in GLib. Upstream fixed it
in commit 7ed5496 ("daemon: report dbus method invocation as handled on
error", 2025-05-08). The fix is in v1.29.0 only.
In 1.26.1, two D-Bus handlers in src/daemon/daemon.c send an error reply and
then return FALSE:
- Notify, when more than 20 notifications are open (MAX_NOTIFICATIONS)
- CloseNotification, when the ID is 0
The error reply consumes the GDBusMethodInvocation. FALSE tells the generated
skeleton that the method is not handled, so the skeleton sends a second error
("Method ... is not implemented") on the same invocation. This is a double
unref. The result is either the warning "g_object_unref: assertion
'G_IS_OBJECT (object)' failed" or the segfault in
g_type_check_instance_is_fundamentally_a.
Reproduced on 26.04 with 1.26.1-1build6, in a private session bus, under
gdb:
gdbus call --session --dest org.freedesktop.Notifications \
--object-path /org/freedesktop/Notifications \
--method org.freedesktop.Notifications.CloseNotification 0
gdb shows two g_dbus_method_invocation_return_error calls on the same
invocation: code 100 from the daemon, then G_DBUS_ERROR_UNKNOWN_METHOD from
g_dbus_interface_skeleton_method_dispatch_real. Then SIGSEGV, with the same
stack as in this report. The "60 x notify-send" reproducer in the description
uses the Notify path.
Verified: the attached resolute package, built from its source package. 20 x
CloseNotification(0), 3 runs: no crash, no warning. The unpatched binary
segfaults on the first call in 3 of 3 runs, at the same libgobject offset
(0x3e301) as in this report. 22 x Notify: one error reply, no warning.
Attached are two debdiffs with the upstream commit as a DEP-3 patch:
- stonking: 1.26.1-1ubuntu1
- resolute (SRU): 1.26.1-1ubuntu0.26.04.1
An SRU template for the description is at the end of this comment.
Upstream commit:
https://github.com/mate-desktop/mate-notification-daemon/commit/7ed54960995ef18d5fff9092b839565080456a40
--- Proposed SRU template ---
[ Impact ]
mate-notification-daemon crashes (SIGSEGV) in two cases:
- a client calls CloseNotification with ID 0
- a client calls Notify while more than 20 notifications are open
In both cases the handler sends a D-Bus error reply and then returns FALSE.
The generated skeleton then sends a second error reply on the same
GDBusMethodInvocation, so the invocation is unreferenced two times.
Users of the MATE desktop see "The application Popup Notifications has closed
unexpectedly", frequently at login, when update-notifier starts the daemon.
The notification that caused the crash is lost.
The fix is upstream commit 7ed5496 (in 1.29.0). The two handlers return TRUE
after the error reply.
[ Test Plan ]
1. In a MATE session, run:
gdbus call --session --dest org.freedesktop.Notifications \
--object-path /org/freedesktop/Notifications \
--method org.freedesktop.Notifications.CloseNotification 0
Expected: the call returns the error "0 is not a valid notification ID".
Then run:
gdbus call --session --dest org.freedesktop.Notifications \
--object-path /org/freedesktop/Notifications \
--method org.freedesktop.Notifications.GetServerInformation
Expected: the call returns the server information. "journalctl -k" shows
no segfault of mate-notificati.
Without the fix, the daemon segfaults in
g_type_check_instance_is_fundamentally_a after the first call.
2. Run:
for i in $(seq 22); do notify-send -t 30000 "test $i"; done
Expected: the daemon continues to run, and the journal shows no
"g_object_unref: assertion 'G_IS_OBJECT (object)' failed" message.
Without the fix, the result of this step is not constant: the critical
message, a crash, or no visible effect. Step 1 is the reliable
reproducer.
3. Regression check: run notify-send "hello". Expected: the notification
shows, and it closes when it expires or when you click its close button.
[ Where problems could occur ]
The change affects only the return value of two D-Bus method handlers, on
their error paths. With TRUE, the GDBus skeleton treats the call as handled
and does not send a second reply. The success paths do not change.
A regression would show as a client that does not get an error reply for
CloseNotification(0), or for Notify above the limit. Such a client would wait
until its D-Bus call times out. Step 1 of the test plan makes sure that the
error reply arrives.
[ Other Info ]
The patch is a cherry-pick of the upstream commit, with only line offsets
changed. Debian has the same bug in 1.26.1-1 (trixie, forky, sid).
** Patch added: "lp2165836_resolute_1.26.1-1ubuntu0.26.04.1.debdiff"
https://bugs.launchpad.net/ubuntu/+source/mate-notification-daemon/+bug/2165836/+attachment/6003095/+files/lp2165836_resolute_1.26.1-1ubuntu0.26.04.1.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2165836
Title:
mate-notification-daemon segfaults in libgobject at session start
(glib 2.88 regression)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mate-notification-daemon/+bug/2165836/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
