Bug 17832 - multiple IP addresses in /etc/hosts (for one hostname) cause programs to access /etc/hosts via the usual library functions to segfault
multiple IP addresses in /etc/hosts (for one hostname) cause programs to acce...
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
: 18108 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2000-09-25 14:52 EDT by Nils Philippsen
Modified: 2008-05-01 11:37 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-10-04 20:00:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Nils Philippsen 2000-09-25 14:52:28 EDT
If there are multiple interfaces on a host and each IP is assigned the same
hostname, programs like pine, talk and others segfault as soon as they try
to resolve hostnames.
Comment 1 Jakub Jelinek 2000-09-26 07:17:33 EDT
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)?
Comment 2 adam.huffman 2000-09-26 08:53:43 EDT
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. localhost.localdomain localhost my.lan.name my
Comment 3 Nils Philippsen 2000-09-26 10:56:27 EDT
The guilty /etc/hosts looked like this:

--- 8< ---		localhost localhost.localdomain		rhlx03.fht-esslingen.de rhlx03           rhlx01.fht-esslingen.de rhlx01 nisserv
rhlx01.rz.fht-esslingen.de www-stud www-stud.fht-esslingen.de 42
42.fht-esslingen.de		itppp0.it.fht-esslingen.de itppp0		rhlx01.fht-esslingen.de rhlx01		rhlx01.fht-esslingen.de rhlx01		rhlx01.fht-esslingen.de rhlx01
--- >8 ---

But even stripped down versions like that:

--- 8< ---		localhost	rhlx01.fht-esslingen.de rhlx01	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.
Comment 4 Alan Cox 2000-10-02 12:47:50 EDT
*** Bug 18108 has been marked as a duplicate of this bug. ***
Comment 5 Jakub Jelinek 2000-10-03 06:58:43 EDT
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).
Comment 6 Nils Philippsen 2000-10-03 10:13:32 EDT
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.
Comment 7 Mike Bremford 2000-10-03 22:01:52 EDT
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.       localhost     tosh.localnet tosh     tosh.localnet tosh     vaio.localnet vaio     aphrodite.localnet aphrodite   demon-gw

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

Cheers... Mike
Comment 8 Jakub Jelinek 2000-10-04 09:17:19 EDT
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?
Comment 9 Mike Bremford 2000-10-04 20:00:03 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.