Bug 25262 - dig from bind-utils 8.2.3 segfaults
Summary: dig from bind-utils 8.2.3 segfaults
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: bind   
(Show other bugs)
Version: 5.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact: David Lawrence
: 26691 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2001-01-30 05:10 UTC by jlewis
Modified: 2007-04-18 16:30 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-08-27 13:19:10 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description jlewis 2001-01-30 05:10:38 UTC
[root@sloth /tmp]# dig @a.root-servers.net lewis.org

; <<>> DiG 8.3 <<>> @a.root-servers.net lewis.org 
Segmentation fault (core dumped)
[root@sloth /tmp]# rpm -q bind-utils
[root@sloth /tmp]# cat /etc/redhat-release 
Red Hat Linux release 5.2 (Apollo)
[root@sloth /tmp]# rpm -q glibc

I emailed Paul Vixie about this as my own bind 8.2.3 rpm for Red Hat 5.x
did the same thing.  It appears to be a problem only on 5.x boxes with
various versions of glibc 2.0.7.  He didn't have much more to offer. 
Nobody on bind-workers has replied.

GNU gdb with Linux/x86 hardware watchpoint and FPU support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
welcome to change it and/or distribute copies of it under certain
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./dig @a.root-servers.net. lewis.org'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  0x40053e5f in __strcasecmp (s1=0xbffeae9c "a.root-servers.net.", 
    s2=0xbffeaa98 "a.root-servers.net.") at
../sysdeps/generic/strcasecmp.c:37: No such file or directory.

It's not any of Red Hat's bind rpm patches either.  Dig compiled from bind
8.2.3 source and no patches is just as broken.

Comment 1 Need Real Name 2001-01-30 20:07:45 UTC
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
will also segfault).

Comment 2 Nalin Dahyabhai 2001-01-30 20:15:03 UTC
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.

Comment 3 epinkert 2001-02-01 18:03:28 UTC
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
[root@wopr /root]# cat /etc/redhat-release
Red Hat Linux release 6.0 (Hedwig)
[root@wopr /root]# rpm -q glibc

Comment 4 jlewis 2001-02-01 18:11:11 UTC
epinkert@wopr.hampshire.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.

Comment 5 scot 2001-02-04 19:48:46 UTC
does Redhat plan to fix this bug for us RH 5.2 users?

Comment 6 Bernhard Rosenkraenzer 2001-02-17 17:51:24 UTC
*** Bug 26691 has been marked as a duplicate of this bug. ***

Comment 7 scot 2001-04-05 16:20:53 UTC
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

Comment 8 Need Real Name 2001-08-27 12:58:11 UTC
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:

Here I've pasted part of the message:

In article <9aigdu$qu@pub3.rc.vix.com>,
 "Jorge Valdes" <jvaldes@sv.cciglobal.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
> to
> 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 
     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@sv.cciglobal.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...

Comment 9 Bernhard Rosenkraenzer 2001-08-27 13:01:27 UTC
Looks like a glibc problem indeed.

I'd suggest replacing

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


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

though, just to be safe.

Comment 10 Jakub Jelinek 2001-08-27 13:19:06 UTC
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.

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