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] |
Date: Fri, 14 Jul 2000 15:56:02 -0700 From: "H . J . Lu" <hjl@lucon.org> On Sat, Jul 15, 2000 at 12:46:45AM +0200, Mark Kettenis wrote: > 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? */ Oops. Looks like I looked in the wrong places. It is 100% ok to call res_close () without calling res_init () first in my glibc 2.1. The fact that it simply works in glibc 2.1 doesn't mean it's right. 1. res_close() is undocumented, it's not in the glibc manual, not on the Linux resolver(3) man page, not on the BIND-4.9.7-REL resolver(3) not on any of the BSD resolver(3) man pages. Heck it's not even exported by the Solaris /usr/lib/libresolv.so.2 library. 2. res_close() is clearly marked with: /* * This routine is for closing the socket if a virtual circuit is used and * the program wants to close it. This provides support for endhostent() * which expects to close the socket. * * This routine is not expected to be user visible. */ Unfortunately this has become a bit less clear in glibc 2.1 because of renaming the origional function to res_close_internal(). 3. Calling res_close() before res_init() makes absolutely no sense. > > 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. Thanks for the info! [After having a struggle with RPM] Looks like a piece of shoddy software to me. I don't think its existence is enough reason for us to put another 512+ bytes in the data segment. A better fix would be to check if RES_INIT is set in _res.options and bail out if it isn't in res_close(). But IMHO pump should be fixed. Unfortunately for Red Hat they make it too hard for me to file a bug report, so they loose. Mark
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |