Alleged bug in resolver code

[H . J . Lu]

On Sat, Jul 15, 2000 at 12:46:45AM +0200, Mark Kettenis wrote:
> Hi HJ,
> 
> Back in may you reported the following:
> 
>    Hi,
> 
>    I am working on several bugs in glibc 2.2. I had an impression that
>    glibc 2.2 was very unstable. I was wondering how many people were
>    using glibc 2.2. To start,
> 
>    There are
> 
>    struct __res_state _res;
> 
>    and
> 
>    void
>    res_close(void) {
> 	   res_nclose(&_res);
>    }
> 
>    void
>    res_nclose(res_state statp) {
> 	   if (statp->_sock >= 0) {
> 		   (void) close(statp->_sock);
> 		   statp->_sock = -1;
> 		   statp->_flags &= ~(RES_F_VC | RES_F_CONN);
> 	   }
>    }
> 
>    since _res._sock is 0, close (0) is called. It is very bad
>    when 0 may be a valid fd for something else.
> 
> I'm willing to believe that you actualy saw if bug, but the suggested
> fix (initializing _res._sock to -1, and doing the same for the
> per-thread resolver state) that was checked in cannot be the right
> solution.  You see, calling res_close() without first sucessfully
> having called res_init(), or calling res_nclose(statp) without
> res_ninit(statp) is simply a programming mistake, and will obviously
> invoke undefined behaviour (such as close(0)).  This behaviour isn't
> any different than what the resolver in glibc 2.1 did.  As such, what
> you describe here obviously isn't a bug.

I have no idea what your glibc 2.1 looks like. Mine has

static int s = -1;      /* socket used for communications */
static int connected = 0;       /* is the socket connected */
static int vc = 0;      /* is the socket a virtual circuit? */

....
static void
res_close_internal()
{
        if (s >= 0) {
                (void) close(s);
                s = -1;
                connected = 0;
                vc = 0;
        }
}

void
res_close ()
{
        __libc_lock_lock (lock);
        res_close_internal ();
        __libc_lock_unlock (lock);
}

It is 100% ok to call res_close () without calling res_init () first
in my glibc 2.1.

> 
> Now there is actually a problem with res_init() in multi-threaded
> programs that might have caused the problems you were seeing.
> Unfortunately your report didn't provide a test-case either.  Could
> you privide one?  If so I'm willing to do some additional testing,
> before sending my updated BIND code to Ulrich.
> 

The program I was having trouble with is pump from Red Hat.


H.J.