Alleged bug in resolver code

[Mark Kettenis <kettenis at wins dot uva dot nl>]

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.

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.

Mark