This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 25262 - dig from bind-utils 8.2.3 segfaults
dig from bind-utils 8.2.3 segfaults
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: bind (Show other bugs)
5.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
David Lawrence
:
: 26691 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-30 00:10 EST by jlewis
Modified: 2007-04-18 12:30 EDT (History)
5 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description jlewis 2001-01-30 00:10:38 EST
[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
bind-utils-8.2.3-0.5.x
[root@sloth /tmp]# cat /etc/redhat-release 
Red Hat Linux release 5.2 (Apollo)
[root@sloth /tmp]# rpm -q glibc
glibc-2.0.7-29.4

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 4.17.0.4 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
are
welcome to change it and/or distribute copies of it under certain
conditions.
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
../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 15:07:45 EST
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).
Comment 2 Nalin Dahyabhai 2001-01-30 15:15:03 EST
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 13:03:28 EST
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
Comment 4 jlewis 2001-02-01 13:11:11 EST
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 14:48:46 EST
does Redhat plan to fix this bug for us RH 5.2 users?
Comment 6 Bernhard Rosenkraenzer 2001-02-17 12:51:24 EST
*** Bug 26691 has been marked as a duplicate of this bug. ***
Comment 7 scot 2001-04-05 12:20:53 EDT
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. 

Comment 8 Need Real Name 2001-08-27 08:58:11 EDT
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@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
> 
> #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@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 09:01:27 EDT
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.
Comment 10 Jakub Jelinek 2001-08-27 09:19:06 EDT
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.