Red Hat Bugzilla – Bug 25262
dig from bind-utils 8.2.3 segfaults
Last modified: 2007-04-18 12:30:59 EDT
[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 220.127.116.11 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.
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).
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
[root@wopr /root]# cat /etc/redhat-release
Red Hat Linux release 6.0 (Hedwig)
[root@wopr /root]# rpm -q glibc
email@example.com: 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
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
Here I've pasted part of the message:
In article <firstname.lastname@example.org>,
"Jorge Valdes" <email@example.com> 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
> 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
> #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
we know about. */
struct gaih_servtuple **lastp = &st;
- for (++tp; tp->name != NULL; ++tp)
+ for (++tp; tp->name != '\0'; ++tp)
struct gaih_servtuple *newp;
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 (firstname.lastname@example.org)
Subject: Re: Dig problems...
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'; ++tp)
for(++tp; tp->name && tp->name != '\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.