Skip site navigation (1)Skip section navigation (2)
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Mutt.19970522173856.john>