seahorse assert failure: seahorse: glib-watch.c:195: timeout_update: Assertion `!t->dead' failed.

[Gustavo Lima]

---------------------------------------------------------
Description: Ubuntu Disco Dingo (development branch)
Release: 19.04
---------------------------------------------------------
seahorse:
  Installed: 3.32-1
  Candidate: 3.32-1
  Version table:
 *** 3.32-1 500
        500 http://br.archive.ubuntu.com/ubuntu disco/main amd64 Packages
        100 /var/lib/dpkg/status
---------------------------------------------------------

I have absolutely no idea why or how. Just collected this report from apport-cli.

Some times receiving "internal error" reports, no details provided, just "Cancel" or "Send report" options. So, I decided to check apport and there was this report.

ProblemType: Crash
DistroRelease: Ubuntu 19.04
Package: seahorse 3.32-1
ProcVersionSignature: Ubuntu 5.0.0-7.8-generic 5.0.0
Uname: Linux 5.0.0-7-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.10-0ubuntu23
Architecture: amd64
AssertionMessage: seahorse: glib-watch.c:195: timeout_update: Assertion `!t->dead' failed.
CurrentDesktop: ubuntu:GNOME
Date: Sun Mar 17 18:09:01 2019
ExecutablePath: /usr/bin/seahorse
InstallationDate: Installed on 2019-03-17 (0 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Alpha amd64 (20190316)
ProcCmdline: /usr/bin/seahorse --gapplication-service
Signal: 6
SourcePackage: seahorse
StacktraceTop:
 __assert_fail_base (fmt=0x7f733ae49588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7f733aecf02d "!t->dead", file=0x7f733aecf000 "glib-watch.c", line=195, function=<optimized out>) at assert.c:92
 __GI___assert_fail (assertion=0x7f733aecf02d "!t->dead", file=0x7f733aecf000 "glib-watch.c", line=195, function=0x7f733aecf1d8 "timeout_update") at assert.c:101
 ?? () from /lib/x86_64-linux-gnu/libavahi-glib.so.1
 ?? () from /lib/x86_64-linux-gnu/libavahi-client.so.3
 ?? () from /lib/x86_64-linux-gnu/libavahi-glib.so.1
Title: seahorse assert failure: seahorse: glib-watch.c:195: timeout_update: Assertion `!t->dead' failed.
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
separator:

[Apport retracing service (apport)]

StacktraceTop:
 raise () from /tmp/apport_sandbox_j8nkf09g/lib/x86_64-linux-gnu/libc.so.6
 abort () from /tmp/apport_sandbox_j8nkf09g/lib/x86_64-linux-gnu/libc.so.6
 ?? () from /tmp/apport_sandbox_j8nkf09g/lib/x86_64-linux-gnu/libc.so.6
 __assert_fail () from /tmp/apport_sandbox_j8nkf09g/lib/x86_64-linux-gnu/libc.so.6
 timeout_update (t=<optimized out>, tv=<optimized out>) at glib-watch.c:193

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Sebastien Bacher (seb128)]

looks like the assert in in libavahi

[Matthew Ruffell (mruffell)]

Still happening under Focal to this day.

[Matthew Ruffell (mruffell)]

This bug is triggered when I went to upgrade the avahi packages as part of a
daily upgrade in focal:

$ sudo apt list --upgradable
Listing... Done
avahi-autoipd/focal 0.7-4ubuntu7 amd64 [upgradable from: 0.7-4ubuntu6]
avahi-daemon/focal 0.7-4ubuntu7 amd64 [upgradable from: 0.7-4ubuntu6]
avahi-utils/focal 0.7-4ubuntu7 amd64 [upgradable from: 0.7-4ubuntu6]
libavahi-client3/focal 0.7-4ubuntu7 amd64 [upgradable from: 0.7-4ubuntu6]
libavahi-common-data/focal 0.7-4ubuntu7 amd64 [upgradable from: 0.7-4ubuntu6]
libavahi-common3/focal 0.7-4ubuntu7 amd64 [upgradable from: 0.7-4ubuntu6]
libavahi-core7/focal 0.7-4ubuntu7 amd64 [upgradable from: 0.7-4ubuntu6]
libavahi-glib1/focal 0.7-4ubuntu7 amd64 [upgradable from: 0.7-4ubuntu6]
libavahi-ui-gtk3-0/focal 0.7-4ubuntu7 amd64 [upgradable from: 0.7-4ubuntu6]

When the dpkg hook is run to restart the avahi service, seahorse looses connection to the avahi-daemon:

Apr 14 16:55:10 ubuntu avahi-daemon[694]: Got SIGTERM, quitting.
Apr 14 16:55:10 ubuntu avahi-daemon[694]: Leaving mDNS multicast group on interface enp1s0.IPv6 with address fe80::daf8:4688:8169:19b5.
Apr 14 16:55:10 ubuntu avahi-daemon[694]: Leaving mDNS multicast group on interface enp1s0.IPv4 with address 192.168.122.34.
Apr 14 16:55:10 ubuntu avahi-daemon[694]: Leaving mDNS multicast group on interface lo.IPv6 with address ::1.
Apr 14 16:55:10 ubuntu avahi-daemon[694]: Leaving mDNS multicast group on interface lo.IPv4 with address 127.0.0.1.
Apr 14 16:55:10 ubuntu seahorse[2622]: failure communicating with to avahi: Daemon connection failed

From there, seahorse hits the assert at: https://github.com/lathiat/avahi/blob/master/avahi-common/simple-watch.c#L273-L282

Apr 14 16:55:10 ubuntu org.gnome.seahorse.Application[2622]: seahorse: glib-watch.c:195: timeout_update: Assertion `!t->dead' failed.

The avahi daemon continues to stop, and then restarts:

Apr 14 16:55:10 ubuntu dbus-daemon[713]: [system] Activating via systemd: service name='org.freedesktop.Avahi' unit='dbus-org.freedesktop.Avahi.service' requested by ':1.114' (uid=0 pid=789 comm="/usr/sbin/cups-browsed " label="/usr/sbin/cups-browsed (enforce)")
Apr 14 16:55:10 ubuntu systemd[1]: Stopping Avahi mDNS/DNS-SD Stack...
Apr 14 16:55:10 ubuntu avahi-daemon[694]: avahi-daemon 0.7 exiting.
Apr 14 16:55:10 ubuntu systemd[1]: avahi-daemon.service: Succeeded.
Apr 14 16:55:10 ubuntu systemd[1]: Stopped Avahi mDNS/DNS-SD Stack.
Apr 14 16:55:10 ubuntu systemd[1]: Starting Avahi mDNS/DNS-SD Stack...

Then apport goes and makes a crash report:

Apr 14 16:55:11 ubuntu avahi-daemon[4364]: Server startup complete. Host name is ubuntu.local. Local service cookie is 3169540412.
Apr 14 16:55:11 ubuntu systemd[1529]: Starting Notification regarding a crash report...
Apr 14 16:55:11 ubuntu update-notifier-crash[4516]: /usr/bin/whoopsie
Apr 14 16:55:11 ubuntu update-notifier-crash[4519]: seahorse

The next interesting thing is, if you launch seahorse, then restart avahi-daemon.service, it prints an error but does not crash:

$ seahorse
$ sudo systemctl restart avahi-daemon.service
(seahorse:6477): seahorse-WARNING **: 17:09:53.344: failure communicating with to avahi: Daemon connection failed

[Elias Rudberg (eliasrudberg)]

Related: bug #1888585 ( https://bugs.launchpad.net/ubuntu/+source/seahorse/+bug/1888585 )

The error "seahorse (seahorse) glib-watch.c → 195 → timeout_update → Assertion `!t->dead'' failed." is listed with hundreds of occurrences each day at https://errors.ubuntu.com/ but there is no bug report assigned to it there, the "Bug report" column is empty. Should it be associated with this bug report, or perhaps with bug #1888585 ?

[Elias Rudberg (eliasrudberg)]

I added some extra debug output in avahi and waited for the error to happen again, in this way found out that the assertion failure happens when the time_event_queue_root(q) call gives NULL so that the "else" part is used in update_timeout() in avahi-core/timeeventq.c:

static void update_timeout(AvahiTimeEventQueue *q) {
    AvahiTimeEvent *e;
    assert(q);

    if ((e = time_event_queue_root(q)))
        q->poll_api->timeout_update(q->timeout, &e->expiry);
    else
        q->poll_api->timeout_update(q->timeout, NULL); <-- assertion failure inside this call
}

So time_event_queue_root(q) gives NULL which means that q->prioq->root is NULL. Why would that happen?

[Elias Rudberg (eliasrudberg)]

After some more digging and having reproduced the issue a few more times, here is what seems to happen.

Seahorse is running, using the avahi library. Seahorse has called avahi_glib_poll_new() and some AvahiTimeout timeouts have been created.

Then things are stopped because the computer is about to be rebooted. Seahorse is closing down and therefore does some cleanup, among other things it calls avahi_glib_poll_free() which calls cleanup_timeouts() which destroys all the timeouts.

However, after the timeouts were destroyed, there still exists a pointer to one of those timeouts in the dispatch_timeout member in a ConnectionData struct. For some reason the dispatch_timeout_callback() function is called at this point, and it does "ConnectionData *d = userdata" and that ConnectionData struct has inside it a dispatch_timeout pointer which is now invalid because the timeout was destroyed, its memory was freed, as a result of the avahi_glib_poll_free() call earlier. dispatch_timeout_callback() passes the ConnectionData *d to request_dispatch() which calls timeout_update() passing the invalid d->dispatch_timeout pointer, which is then used and happens to point to some garbage which gives the assertion failure.

Not sure exactly how to fix the problem, but it seems bad that pointers to destroyed data structures are still lying around, maybe things should be destroyed in a different order.

[Brian Murray (brian-murray)]

I encountered this crash after a fresh install of Ubuntu 22.04 LTS and reported it to the Ubuntu Error Tracker. After doing so I was able to find the following crash bucket with tens of thousands of incidents:

https://errors.ubuntu.com/bucket/?id=/usr/bin/seahorse%3Aseahorse%3A%20glib-watch.c%3A195%3A%20timeout_update%3A%20Assertion%20%60%21t-%3Edead%27%20failed.

There's something wrong with the URL quoting in the above link but if you go to the following crash:

https://errors.ubuntu.com/oops/20b497f8-1802-11ed-a548-fa163e55efd0

You can navigate to the bucket from the Error Tracker.

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1820584

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Utkarsh Gupta (utkarsh)]

Ubuntu 22.10 (Kinetic Kudu) has reached end of life, so this bug will not be fixed for that specific release.