Bug 25262

It is not only dig that segfaults.  host when used to do more complex queries
than host hostname also segfaults (for example host foo -c chaos -t txt
version.bind
will also segfault).

It appears to happen consistently when you pass either "host" or "dig" a
hostname (instead of an IP address) when specifying a nameserver to query.

It seems that this bug also applies to RH 6.0.

[root@wopr /root]# /usr/bin/dig @ns.internic.net . ns

; <<>> DiG 8.3 <<>> @ns.internic.net . ns
Segmentation fault (core dumped)
[root@wopr /root]# rpm -q bind-utils
bind-utils-8.2.3-0.5.x
[root@wopr /root]# cat /etc/redhat-release
Red Hat Linux release 6.0 (Hedwig)
[root@wopr /root]# rpm -q glibc
glibc-2.1.3-21

epinkert.edu: it's a problem with the dig from the 5.2 RPM...it's
broken whether you use it with 5.2, 6.0, 6.2, etc.  With Red Hat 6.0, you should
be able to use the bind-utils RPM for 6.2 and not run into this problem.

does Redhat plan to fix this bug for us RH 5.2 users?

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

FWIW, recently dig started working on two of my RH 5.2 systems but not all of
them.  I'm not sure what changed that allows the following command to work:

'dig @ns.internic.net . ns'

I have 2 other RH 5.2 systems and dig still core dumps on them.  I've compared
complete installed RPM lists between the working and non working systems and can
not seem to pinpoint the difference.  All boxes are running 2.0.39 kernel with
glibc-2.0.7-29.4 and the other latest RPM updates from RH.

working systems: 386sx and Cyrix 233 MMX
non-working systems: P5-150MMX laptop, PII-400 desktop

I also tried installing the RH 5.2 version (bind-utils-8.2.3-0.5.x) on a RH 6.2
box, and 'dig @ns.internic.net . ns' works there as well.

The following does work on all systems though: 'dig ns.internic.net . ns'

I'm not sure how else to track down the difference.  Any suggestions would be
appreciated. 

I found someone talking about this problem at a newsgroup
Perhaps this will give someone a clue.

I don't know much about C++ , so perhaps it just crap.
So sorry if I spam the bugzilla

The URL:
http://groups.google.com/groups?hl=en&safe=off&threadm=9anqur%245im%
40pub3.rc.vix.com&rnum=11&prev=/groups%3Fq%3Ddig%2Bsegmentation%26hl%3Den%
26safe%3Doff%26start%3D10%26sa%3DN

Here I've pasted part of the message:
------------------------------------------------------------


In article <9aigdu$qu.vix.com>,
 "Jorge Valdes" <jvaldes.net> wrote:

> I recently installed BIND 8.2.3-REL for both my primary and secondary DNS
> servers, and use dig extensively to check delegations for the domains that I
> administer... running on a Linux server w/2.0.34 kernel
> 
> Today, I got a core dump when trying to use Dig 8.3 with the following
> statement:
> 
> dig @cir.red.sv acsasal.com.sv ns
> 
> If I don't use the "@" part it works fine...
> 
> Any sugestions??

Yes, see my earlier message which I repeat below for your amusement:

> > I'm getting segmentation fault on RH7.0 systems (tried on at least 2
> > different i386 systems) whenever I specify an explicit name server to
> > dig, host or nslookup. I.e., if I do
> > 
> > dig @x or host @x
> > 
> > or nslookup followed by "server x" all fail with segmentation fault.
> > This happens with all versions of bind from 9.1.0 up to 9.1.1.rc7.
> > ..etc etc...
> 
> Sorry to follow-up my own post, but some of you may be interested in
> what I've found out. It turns out there is soemthing wrong with the
> getaddrinfo() routine that is in the libc.so.6 that is part of
> glibc-2.2.1-3 (and possibly other glibc 2.2.X RPMs as well). I wrote a
> little program that just calls getaddrinfo() and it dies with a
> segmentation fault exactly as dig, host etc.
> 
> Anyway, if you're getting this, the workaround for me is to, after
> running ./configure, to edit config.h and manually change the line
> 
> #define HAVE_GETADDRINFO 1
> 
> to
> 
> #undef HAVE_GETADDRINFO
> 
> before doing a "make".
> 
> This forces the bind code to call gethostbyname() instead, which appears
> to work fine.

The bug is still in the latest glibc (2.2.2). I have tracked down the 
offending line in the glibc srcs, by the way, and will report it to the 
glibc people, so hopefully it will be incorporated in an official 
release of glibc > 2.2.2. If, in the meantime, you can apply the 
following patch to the glibc srcs:

--- sysdeps/posix/getaddrinfo.c.gai Wed Jan 24 08:57:10 2001
+++ sysdeps/posix/getaddrinfo.c Thu Apr  5 11:43:38 2001
@@ -414,7 +414,7 @@
       /* Neither socket type nor protocol is set.  Return all socket 
types
     we know about.  */
       struct gaih_servtuple **lastp = &st;
-      for (++tp; tp->name != NULL; ++tp)
+      for (++tp; tp->name[0] != '\0'; ++tp)
    {
      struct gaih_servtuple *newp;

-- 

Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK
Phone: (+44) 24 76 419996  Fax: (+44) 24 76 690690



Message 3 in thread 
From: Jorge Valdes (jvaldes.net)
Subject: Re: Dig problems... 
Newsgroups: comp.protocols.dns.bind
View this article only 
Date: 2001-04-07 07:56:06 PST 
 

The interesting thing is that it sometimes works and sometimes it does not
work... I still have not recompiled BIND, and the construct works
sometimes... This tells me that something else is wrong...

Looks like a glibc problem indeed.

I'd suggest replacing

for(++tp; tp->name[0] != '\0'; ++tp)

with

for(++tp; tp->name && tp->name[0] != '\0'; ++tp)

though, just to be safe.

This is completely unrelated.
This bug was introduced in glibc on 2001-01-21 and I've fixed it on
2001-02-01, so it cannot possibly have anything to do with how dig works
with glibc 2.0.7 resp. 2.1.3.