Date: Thu, 22 May 1997 17:38:56 -0500 From: john@dexter.starfire.mn.org (John Lind) To: cabal95@dal.net Cc: freebsd-questions@freebsd.org, john@starfire.mn.org Subject: Re: bin/3622: gethostbyname fails for file descriptors above 255 Message-ID: <Mutt.19970522173856.john@dexter.starfire.mn.org> In-Reply-To: <3384C34D.23AD@dal.net>; from Cabal95 on May 22, 1997 15:06:05 -0700 References: <3384C34D.23AD@dal.net>
index | next in thread | previous in thread | raw e-mail
Cabal95 writes:
> john@starfire.mn.org wrote:
> > Number: 3622
> > Category: bin
> > Synopsis: gethostbyname fails for file descriptors above 255
> >
> > Description:
> >
> > gethostbyname() fails for a perfectly good domain name once a program
> > already has file descriptors 0-255 open. I have not yet tracked
> > this down to find if it is specific to gethostbyname, or if it
> > may be the underlying infrastructure, or possibly even into the kernel
> > (in which case the category specified for this report will be wrong).
>
> After compiling a debug version of FreeBSD 2.2.1-Release libc.a 3.0 and
> running your test program below through gdb 4.16, the specific cause of
> this problem appears to be caused by the following code in
> /usr/src/lib/libc/net/res_send.c(I'm sorry, line # not available)
> s = socket(PF_INET, SOCK_DGRAM, 0);
> ...
> if (s+1 > FD_SETSIZE) {
> Perror(stderr, "res_send: too many files");
> _res_close();
> goto next_ns;
> }
>
> When compiling the libs, FD_SETSIZE on most(all?) systems is 256,
> defined in /usr/include/sys/types.h.
>
> > Fix:
>
> One way I fixed this on my system was to recompile libc.a with
> FD_SETSIZE defined to a higher value. I used 1024 and have not had any
> of the described problems since doing that.
Yes! This makes sense. A lot of sense. It would be nice to have a way
to link it to the kernel parameters, but that may be more generality
than most people/processes need.
> Another way was to go into the /usr/src/lib/libc/net/res_send.c, take
> out:
> if (s+1 > FD_SETSIZE) {
> Perror(stderr, "res_send: too many files");
> _res_close();
> goto next_ns;
> }
> and change:
> select(s+1, &dsmask, (fd_set *)NULL, (fd_set *)NULL, &timeout)
> to:
> select(1, &dsmask, (fd_set *)NULL, (fd_set *)NULL, &timeout)
>
> This also works, but there may be problems i'm unaware of, since
> select() appears to be an internal kernel function, and I don't have the
> kernel source at this time.
This WORKS? I'm very concerned about this. Looking at the "FD_SET"
macro, it would appear that you'd be setting a bit in word beyond the
size of "dsmask". For FD_SETSIZE of 256, the number of longs (fd_mask)
for fd_set is 8, but 256/NFDBITS is 8, not 0-7.
Furthermore, with a first parameter of 1, select will only check bits
corresponding to fd's (0 -- (1-1)) which is a pretty short list...
Am I missing something here?
> Although, from my programming experience on linux, you can call select()
> with FD's greater than FD_SETSIZE, just not a group of FD's who's total
> number is greater than FD_SETSIZE. But perhaps this is different under
> FreeBSD?
Looking at the FreeBSD implementation, this seems VERY dangerous. The
bit mask is a linear, non-biased (0-based) mask. Perhaps in Linux,
it is an array of values, but in FreeBSD, it is a bit mask. If Linux
uses an array of values, that would also explain why the earlier code
I am concerned about would work, and it would probably change the
interpretation of the first parameter of select, as well, but I'm only
speculating.
In summary, it looks like setting FD_SETSIZE to a larger value is the
most nearly correct readily available solution, and the possibility of
a more general solution getting the actual kernel limit of file
descriptors does exit, but it would considerably increase the complexity
of the run-time code, partially by eliminating the run-time constant
calculations, at a benefit to a very small segment of the user
community.
John Lind, Starfire Consulting Services
E-mail: john@starfire.MN.ORG USnail: PO Box 17247, Mpls MN 55417
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Mutt.19970522173856.john>