This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |