Bug 17832

Do you have an example of such /etc/hosts? Does it segfault even if there is
just eth0 and some IP aliases (e.g. eth0:1)?

I had a related problem, on a clean install

/etc/hosts did not have a line for my eth0 address, but
it did have the intended eth0 hostname and alias, on the 
same line as the loopback address

i.e.
127.0.0.1 localhost.localdomain localhost my.lan.name my

The guilty /etc/hosts looked like this:

--- 8< ---
127.0.0.1		localhost localhost.localdomain
134.108.34.13		rhlx03.fht-esslingen.de rhlx03
134.108.34.10           rhlx01.fht-esslingen.de rhlx01 nisserv
rhlx01.rz.fht-esslingen.de www-stud www-stud.fht-esslingen.de 42
42.fht-esslingen.de
134.108.57.99		itppp0.it.fht-esslingen.de itppp0
134.108.34.9		rhlx01.fht-esslingen.de rhlx01
134.108.51.9		rhlx01.fht-esslingen.de rhlx01
134.108.56.9		rhlx01.fht-esslingen.de rhlx01
--- >8 ---

But even stripped down versions like that:

--- 8< ---
127.0.0.1		localhost
134.108.34.10	rhlx01.fht-esslingen.de rhlx01
134.108.34.9	rhlx01.fht-esslingen.de rhlx01
--- >8 ---

caused programs like pine, talk, ... to crash.

A few words on the setup on that machine: It's got an Acenic Gigabit Ethernet
interface, using three VLANs on eth0 and multiple IPs in one VLAN (vlan2). The
programs crash regardless of whether the (namewise) duplicate lines are in the
same VLAN or in different ones.

*** Bug 18108 has been marked as a duplicate of this bug. ***

Ouch, I cannot reproduce it, neither the case where there are different IPs,
FQ hostname and hostname without domain (like above, one of the IPs is eth0
and one is eth0:1) nor duplicate lines in hosts (as #18108 speaks about)
Can you please run the fauling programs under gdb and send me a backtrace
(glibc comes with full debugging info so the backtrace should be readable).
Thanks.

Hmmm, I cannot reproduce it here anymore, too. Sadly I cannot say which packages
have been updated since it didn't work (I'm not the only person messing with
this machine). We might as well blame this on some stray old packages which have
been updated in the meantime.

I've just upgraded my core system to Redhat 7.0 and I was getting this too. 
Here's the top of a stacktrace from sendmail, but I got identical traces from 
wget, ncftp (although not ftp!) and a bunch of others.

#0  0x401c642b in __stpcpy () from /lib/libc.so.6
#1  0x4026e3e0 in _nss_files_gethostbyname_r (name=0x40036440 "tosh",
    result=0xbfffb7d0, buffer=0x8066220 "@(", buflen=1024, errnop=0x40261140,
    herrnop=0xbfffb8e8) at nss_files/files-hosts.c:262
#2  0x40231700 in __gethostbyname_r (name=0x40036440 "tosh",
    resbuf=0x402631a0, buffer=0x8066220 "@(", buflen=1024, result=0xbfffb8e0,
    h_errnop=0xbfffb8e8) at ../nss/getXXbyYY_r.c:191
#3  0x4022fa54 in gethostbyname (name=0x40036440 "tosh")
    at ../nss/getXXbyYY.c:127

I have upgraded glibc, glibc-devel, gcc, binutils, compat-glibc, bind, bind-
utils amongst others to redhat 7.0 versions, others have not been changed. I 
installed the new wget too but was still getting the problem.

On reading this bug report I modified my hosts file (see below) and commented 
out the lines beginning with 192 (not a huge problem since I'm running bind as 
well), and it started working. I have two network cards, hence the two subnets. 
Here's my original hosts file.

127.0.0.1       localhost
192.168.0.1     tosh.localnet tosh
192.168.1.1     tosh.localnet tosh
192.168.0.2     vaio.localnet vaio
192.168.1.2     aphrodite.localnet aphrodite
158.152.1.222   demon-gw


Let me know if there's any more info I can supply to narrow this down.

Cheers... Mike

Actually, I think this bug could be related to #17019, I think I have fixed
something like that on Sep, 2th. Can you guys who are able to reproduce it
e.g. try ftp://ultra.linux.cz/private/glibc, which, altough quite old snapshot,
should contain that fix?

This does indeed fix the problem. I installed ftp://ultra.linux.cz/private/glibc/glibc-2.1.93-2.i386.rpm and it worked a treat.