Comment 25 for bug 183652

Here is a backtrace I dumped with some home-built debug packages :

#0 0xb7c84996 in *__GI_raise (sig=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0xb7c86221 in *__GI_abort () at abort.c:88
#2 0xb7c7ddb0 in *__GI___assert_fail (assertion=0xb7b5322b "name",
    file=0xb7b52a50 "entrygroup.c", line=424,
    function=0xb7b52be0 "avahi_entry_group_add_service_strlst") at assert.c:78
#3 0xb7b4caa2 in avahi_entry_group_add_service_strlst (group=0x80dd5c8,
    interface=-1, protocol=-1, flags=0, name=0x0, type=0x80dd398 "_ipp._tcp",
    domain=0x80dbf58 "local", host=0x0, port=631, txt=0x80db7a8)
    at entrygroup.c:424
#4 0xb7e8ece5 in reg_create_service (sdref=0x80dd540) at compat.c:923
#5 0xb7e8f135 in reg_client_callback (s=0x80db878,
    state=AVAHI_CLIENT_S_RUNNING, userdata=0x80dd540) at compat.c:996
#6 0xb7b4935d in client_set_state (client=0x80db878,
    state=AVAHI_SERVER_RUNNING) at client.c:101
#7 0xb7b4ab41 in filter_func (bus=0x80d91d8, message=0x80e12f0,
    userdata=0x80db878) at client.c:188
#8 0xb7ea2c22 in dbus_connection_dispatch () from /usr/lib/libdbus-1.so.3
#9 0xb7b520ec in dispatch_timeout_callback (t=0x80e17d8, userdata=0x0)
    at ../avahi-common/dbus-watch-glue.c:103
#10 0xb7b5c95a in timeout_callback (t=0x6) at simple-watch.c:449
#11 0xb7b5cc11 in avahi_simple_poll_dispatch (s=0x80d91d8)
    at simple-watch.c:562
#12 0xb7e90792 in DNSServiceProcessResult (sdref=0x80dd540) at compat.c:497
#13 0x08064678 in cupsdUpdateDNSSDBrowse (p=0x80cd7b0) at dirsvc.c:1364
#14 0x0808f06e in cupsdDoSelect (timeout=1) at select.c:455
#15 0x0806a660 in main (argc=2, argv=0xbf92eb74) at main.c:746

In fact, it is entirely an avahi problem :
reg_create_service calls avahi_entry_group_add_service_strlst with sdref->service_name_chosen as the 'name' argument.
As sdref->service_name_chosen is null, assert(name) launches the abort of the program.

Before calling reg_create_service, reg_client_callback correctly checks if the sdref->service_name_chosen pointer is null and corrects it, but the check is in a conditional statement executed if the sdref->service_name pointer is null (in this case it corrects it with a pointer to the hostname of the client)

So a basic fix is to copy the check outside the conditional statement, and to make the check correct 'service_name_chosen' with a pointer to a copy of the value 'service_name'

After having testing my own fix (with success), I checked upstream, and in fact a similar fix has already been committed:
http://avahi.org/changeset/1536
http://avahi.org/ticket/154
and is officially available since version 0.6.22 (so in fact hardy should be immune to this bug, is it ? That would explain why Till do not succeed to trigger it/).

In fact as the fix was backported in Debian version 0.6.21-2, released in unstable on September 9, so maybe with a little more luck, gutsy could have avoided this bug by being inspired to backport it too ;)