Bug#950669: cups-browsed: segfault at 0 ip 00000000f79ffb5b sp 00000000fffd3828 error 4 in libc-2.29.so
Dixi quod…
> No systemd here, but I wasn’t aware that something like
> corekeeper exists and will have a look.
Aaaand we have a coredump! ;-)
(gdb) bt
#0 __strncasecmp_l_sse42 () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:199
#1 0x565fc6d7 in is_local_hostname (host_name=<optimized out>) at utils/cups-browsed.c:9140
#2 0x565fea0a in resolve_callback (r=<optimized out>, interface=4, protocol=<optimized out>,
event=AVAHI_RESOLVER_FAILURE, name=<optimized out>, type=<optimized out>, domain=0x57826250 "local",
host_name=0x0, address=0x0, port=0, txt=0x0, flags=(unknown: 0), userdata=0x577feec0)
at utils/cups-browsed.c:9991
#3 0xf7f0270f in avahi_service_resolver_event (client=client@entry=0x577feec0,
event=event@entry=AVAHI_RESOLVER_FAILURE, message=message@entry=0x577df760) at resolver.c:165
#4 0xf7efdfd7 in filter_func (bus=<optimized out>, message=<optimized out>, userdata=<optimized out>)
at client.c:258
#5 0xf7590367 in dbus_connection_dispatch () from /lib/x86_64-linux-gnux32/libdbus-1.so.3
#6 0xf7f048d8 in dispatch_timeout_callback (t=<optimized out>, userdata=<optimized out>)
at ../avahi-common/dbus-watch-glue.c:105
#7 0xf7ef593c in ?? () from /usr/lib/x86_64-linux-gnux32/libavahi-glib.so.1
#8 0xf7c0f533 in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnux32/libglib-2.0.so.0
#9 0xf7c0f7d0 in ?? () from /usr/lib/x86_64-linux-gnux32/libglib-2.0.so.0
#10 0xf7c0fa8f in g_main_loop_run () from /usr/lib/x86_64-linux-gnux32/libglib-2.0.so.0
#11 0x565e8c63 in main (argc=1, argv=<optimized out>) at utils/cups-browsed.c:12337
(gdb) frame 3
#3 0xf7f0270f in avahi_service_resolver_event (client=client@entry=0x577feec0,
event=event@entry=AVAHI_RESOLVER_FAILURE, message=message@entry=0x577df760) at resolver.c:165
165 r->callback(r, r->interface, r->protocol, event, r->name, r->type, r->domain, NULL, NULL, 0, NULL, 0, r->userdata);
(gdb) print *r
$1 = {path = 0x5780e4e0 "/Client4000/ServiceResolver3", client = 0x577feec0,
callback = 0x565fe820 <resolve_callback>, userdata = 0x577feec0, service_resolvers_next = 0x0,
service_resolvers_prev = 0x57824cc0, name = 0x57821a60 "pr-bn-marketing-a2", type = 0xf5207ec0 "_ipp._tcp",
domain = 0x57826250 "local", interface = 4, protocol = 1}
(gdb) frame 2
#2 0x565fea0a in resolve_callback (r=<optimized out>, interface=4, protocol=<optimized out>,
event=AVAHI_RESOLVER_FAILURE, name=<optimized out>, type=<optimized out>, domain=0x57826250 "local",
host_name=0x0, address=0x0, port=0, txt=0x0, flags=(unknown: 0), userdata=0x577feec0)
at utils/cups-browsed.c:9991
9991 recheck_timer ();
(gdb) frame 1
#1 0x565fc6d7 in is_local_hostname (host_name=<optimized out>) at utils/cups-browsed.c:9140
9140 if (strncasecmp(host_name, host, strlen(host)) == 0 &&
(gdb) print host
$1 = 0x578371b0 "127.0.0.1"
(gdb) print cupsArrayFirst(local_hostnames)
You can't do that without a process to debug.
(gdb) x/39xw local_hostnames
0x577ddf40: 0x00000010 0x00000010 0x00000000 0x0000000f
0x577ddf50: 0x00000001 0x00000000 0x00000000 0x00000000
0x577ddf60: 0x00000000 0x00000000 0x00000000 0x00000000
0x577ddf70: 0x00000000 0x00000000 0x00000000 0x00000000
0x577ddf80: 0x00000000 0x00000000 0x00000000 0x00000000
0x577ddf90: 0x00000000 0x00000000 0x00000000 0x00000000
0x577ddfa0: 0x00000000 0x00000000 0x00000000 0x00000000
0x577ddfb0: 0x00000000 0x00000000 0x00000000 0x00000000
0x577ddfc0: 0x00000000 0x00000000 0x00000000 0x00000000
0x577ddfd0: 0x00000000 0x00000000 0x577d76d0
(gdb) x/s *0x577d76d0
0x578371b0: "127.0.0.1"
Hmm, that’s host, so the optimised-out host_name might be the culprit.
Ouch. With a bit of bad luck, the coredump is from a slightly older
binary package.
Oh… yes…
Start-Date: 2020-02-17 12:26:22
Commandline: apt-get --purge dist-upgrade
Requested-By: tglase (2339)
Upgrade: cups-filters:x32 (1.27.0-2, 1.27.1-1), libcupsfilters1:x32 (1.27.0-2, 1.27.1-1), libfontembed1:x32 (1.27.0-2, 1.27.1-1), cups-filters-core-drivers:x32 (1.27.0-2, 1.27.1-1), cups-browsed:x32 (1.27.0-2, 1.27.1-1)
End-Date: 2020-02-17 12:26:45
… so it actually crashed during the last upgrade. Lemme downgrade the
packages from snapshot.d.o…
(gdb) bt
#0 __strncasecmp_l_sse42 () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:199
#1 0x565fc6d7 in is_local_hostname (host_name=<optimized out>) at utils/cups-browsed.c:9140
#2 0x565fea0a in resolve_callback (r=<optimized out>, interface=4, protocol=<optimized out>,
event=AVAHI_RESOLVER_FAILURE, name=<optimized out>, type=<optimized out>, domain=0x57826250 "local",
host_name=0x0, address=0x0, port=0, txt=0x0, flags=(unknown: 0), userdata=0x577feec0)
at utils/cups-browsed.c:9991
[…]
(gdb) frame 2
#2 0x565fea0a in resolve_callback (r=<optimized out>, interface=4, protocol=<optimized out>,
event=AVAHI_RESOLVER_FAILURE, name=<optimized out>, type=<optimized out>, domain=0x57826250 "local",
host_name=0x0, address=0x0, port=0, txt=0x0, flags=(unknown: 0), userdata=0x577feec0)
at utils/cups-browsed.c:9991
warning: Source file is more recent than executable.
9991 recheck_timer ();
(gdb) frame 1
#1 0x565fc6d7 in is_local_hostname (host_name=<optimized out>) at utils/cups-browsed.c:9140
9140 if (strncasecmp(host_name, host, strlen(host)) == 0 &&
Hm, doesn’t seem to change anything (maybe part of the debugging information
was written to the core file with the new dbgsym package already installed
and copied from there?). The call of is_local_hostname() most likely is the
one in resolve_callback() though:
9772 is_local_hostname(host_name)) {
And indeed: host_name comes from the function signature (parameter)
unchanged, and, as we can see in the backtrace, is NULL. It gets filled
from the decidedly not-NULL r->name in the caller though, so we most
likely hit a stack smash.
Hm, actually… this seems like the culprit:
9770 update_netifs(NULL);
If we look at update_netifs() we see that it removes and free()s
a number of list elements and lists. Perhaps it causes host_name
to become NULL? Hmm, not likely, the pointer should have been
copied to the stack… sorry, out of ideas (and got a headache).
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
**********
Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.
Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.
**********
Reply to: