[avahi] How to enable avahi debug log messages?

[Elias Rudberg]

Hi again,

Regarding the !t->dead assertion failure problem 
(https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1820584):

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. The dispatch_timeout_callback() 
function passes the ConnectionData *d to request_dispatch() which calls 
timeout_update() passing the invalid d->dispatch_timeout pointer, which 
is then dereferenced 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. Anyway, I hope the above can be 
helpful for someone who understands more about how avahi works, to come 
up with a fix.

Best regards,
Elias


On 2021-02-06 19:06, Elias Rudberg wrote:
> Hi Trent, thanks for answering!
> 
> I just had the assertion failure again and got one more piece of 
> information. I had added my own fprintf statement just before the assert 
> in avahi-glib/glib-watch.c timeout_update() like this:
> 
>      fprintf(stderr, "t->dead = %d\n", (int)t->dead);
> 
> and it gave t->dead = 2081423376 which was surprising because I thought 
> it was supposed to be only 1 or 0 (TRUE or FALSE).
> 
> Perhaps it could be some sort of memory corruption then, or that a 
> timeout somehow gets used after it was destroyed? Maybe running it 
> through a tool like valgrind could help?
> 
> Best regards,
> Elias
> 
> 
> On 2021-02-03 15:43, Trent Lloyd wrote:
>> Modify or override the systemd service to pass the --debug flag on 
>> startup and it will log them. You can also run it manually but you 
>> have to mask and stop avahi-daemon which is a bit fiddly to do 
>> reliably due to both dbus and Unix socket activation.
>>
>> I saw your reply on that launchpad earlier too if I have any ideas 
>> I’ll update it the bug. Thanks for the extra info!
>>
>> - Trent
>>
>>> On 3 Feb 2021, at 10:26 pm, Elias Rudberg <mail at eliasrudberg.se> wrote:
>>>
>>> Hello,
>>>
>>> I am having this avahi assertion failure problem:
>>>
>>> https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1820584
>>>
>>> In the code I see some avahi_log_debug(...) calls and I was thinking 
>>> that if that logging was enabled maybe it would give some clues about 
>>> what goes wrong.
>>>
>>> How is debug logging enabled?
>>>
>>> Are there other debug features that could be used to investigate 
>>> problems like the above assertion failure, if so how to turn those on?
>>>
>>> This is in Ubutu 20.04 with avahi 0.7.
>>>
>>> Best regards,
>>> Elias
>>> _______________________________________________
>>> avahi mailing list
>>> avahi at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/avahi
>>
>> _______________________________________________
>> avahi mailing list
>> avahi at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/avahi
>>