Description of problem: traceroute <any address> Version-Release number of selected component: traceroute-2.1.0-2.fc24 Additional info: reporter: libreport-2.7.2 backtrace_rating: 3 cmdline: traceroute www.bbc.co.uk crash_function: __pthread_initialize_minimal_internal executable: /usr/bin/traceroute global_pid: 5888 kernel: 4.8.4-200.fc24.x86_64 pkg_fingerprint: 73BD E983 81B4 6521 pkg_vendor: Fedora Project runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 __pthread_initialize_minimal_internal at nptl-init.c:322 #1 _init at ../sysdeps/x86_64/crti.S:72 #2 ?? #3 call_init at dl-init.c:58 #5 _dl_init at dl-init.c:87 #6 dl_open_worker at dl-open.c:564 #7 _dl_catch_error at dl-error.c:187 #8 _dl_open at dl-open.c:649 #9 do_dlopen at dl-libc.c:87 #10 _dl_catch_error at dl-error.c:187
Created attachment 1219438 [details] File: backtrace
Created attachment 1219439 [details] File: cgroup
Created attachment 1219440 [details] File: core_backtrace
Created attachment 1219441 [details] File: dso_list
Created attachment 1219442 [details] File: environ
Created attachment 1219443 [details] File: exploitable
Created attachment 1219444 [details] File: limits
Created attachment 1219445 [details] File: maps
Created attachment 1219446 [details] File: mountinfo
Created attachment 1219447 [details] File: namespaces
Created attachment 1219448 [details] File: open_fds
Created attachment 1219449 [details] File: proc_pid_status
Created attachment 1219450 [details] File: var_log_messages
Additional information: I'm on a VPN (PPTP). $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 enp0s8 10.0.0.0 0.0.0.0 255.255.255.0 U 50 0 0 ppp0 10.0.0.42 0.0.0.0 255.255.255.255 UH 50 0 0 ppp0 192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s8 213.218.195.63 192.168.1.1 255.255.255.255 UGH 0 0 0 enp0s8 $ route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface Segmentation fault (core dumped) Very similar problem, according to GDB: #0 0x00007ffff01fecfe in __pthread_initialize_minimal_internal () from /lib64/libpthread.so.0 #1 0x00007ffff01fe549 in _init () from /lib64/libpthread.so.0 #2 0x00007ffff04157b0 in ?? () from /lib64/libnss_mdns4_minimal.so.2 ... #13 0x00007ffff782373a in gethostbyaddr_r@@GLIBC_2.2.5 () from /lib64/libc.so.6 #14 0x00007ffff782b978 in gni_host_inet_name.isra () from /lib64/libc.so.6
"route -n" vs. "route" -- looks like something wrong in DNS resolving code. Reassign to glibc.
Would you please try to reproduce this with glibc-debuginfo and nss-mdns-debuginfo install, and post “bt full” output? Thanks.
Created attachment 1219465 [details] Backtrace from route Attached backtrace after running route.
Created attachment 1219466 [details] Backtrace from traceroute Attached backtrace from running traceroute.
Could you run “rpm -V glibc nss-mdns” and paste the output, please? I can't explain the backtraces you get based on the file contents of /lib64/libnss_mdns4_minimal.so.2, so maybe the file is corrupted.
# rpm -V glibc nss-mdns [no output] # rpm -V glibc-debuginfo nss-mdns-debuginfo [no output] (Needed to be root to read two files for glibc in /usr/sbin) I can reproduce the issue if I add any non-local network destination in my routing tables, e.g. # route add www.google.co.uk gw 192.168.1.99 # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default BrightBox.ee 0.0.0.0 UG 100 0 0 enp0s8 Segmentation fault (core dumped) # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 enp0s8 172.217.23.3 192.168.1.99 255.255.255.255 UGH 0 0 0 enp0s8 192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s8
Hmm, can you run route under valgrind, using “valgrind route”? Maybe this is plain old memory corruption. I will try to replicate this, but the issue may depend on your local network and its mDNS responders.
Created attachment 1219510 [details] Output of valgrind Attached output of valgrind (success + failure cases).
Still no idea. Does this crash as well: python -c 'import socket; print socket.getnameinfo(("172.217.23.3", 80), 0)' Or this? python -c 'import socket; print socket.getnameinfo(("192.168.1.99", 80), 0)'
$ python -c 'import socket; print socket.getnameinfo(("172.217.23.3", 80), 0)' ('lhr35s01-in-f3.1e100.net', 'http') $ python -c 'import socket; print socket.getnameinfo(("192.168.1.99", 80), 0)' ('192.168.1.99', 'http') From a quick glance at the source along with gdb, it's getting stuck on: THREAD_SETMEM (pd, cpuclock_offset, GL(dl_cpuclock_offset)); If setting that field fails, why do the previous ones (lines 317+318) succeed?
(In reply to mj.wilson.uk from comment #24) > $ python -c 'import socket; print socket.getnameinfo(("172.217.23.3", 80), > 0)' > ('lhr35s01-in-f3.1e100.net', 'http') > > $ python -c 'import socket; print socket.getnameinfo(("192.168.1.99", 80), > 0)' > ('192.168.1.99', 'http') Next candidate: python -c 'import socket; print socket.getnameinfo(("255.255.255.255", 80), 0)' > From a quick glance at the source along with gdb, it's getting stuck on: > > THREAD_SETMEM (pd, cpuclock_offset, GL(dl_cpuclock_offset)); > > If setting that field fails, why do the previous ones (lines 317+318) > succeed? This code should not run *at all*. It is for libpthread initialization, but libnss_mdns4_minimal.so.2 isn't linked against libpthread. Maybe the code is in fact loading *another* NSS module after libnss_mdns4_minimal.so.2, and the backtrace is misleading because the stack has been corrupted. What's the contents of the “hosts” line in /etc/nsswitch.conf? What happens if you run “LD_DEBUG=files /sbin/route” in the crashing case?
Created attachment 1219526 [details] LD_DEBUG=files route /etc/nsswitch.conf: hosts: files dns wins mdns4_minimal myhostname mymachines Seems to be unaltered from the rpm (AFAICT). Attached the output with LD_DEBUG=files.
Okay, I can reproduce it after adding “wins“ to the “hosts” line. Now we are getting somewhere!
Reduced test case: #include <dlfcn.h> #include <err.h> #include <stdio.h> int main (void) { void *handle = dlopen ("libnss_wins.so.2", RTLD_LAZY); printf ("handle: %p\n", handle); printf ("error: %s\n", dlerror ()); handle = dlopen ("libnss_mdns4_minimal.so.2", RTLD_LAZY); printf ("handle: %p\n", handle); printf ("error: %s\n", dlerror ()); } This is triggered because loading libnss_wins.so.2 fails due to a missing library (libreplace-samba4.so), for which libnss_wins.so.2 as a DT_NEEDED entry.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fixed in glibc 2.25.