From owner-freebsd-questions Thu May 22 15:39:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA13815 for questions-outgoing; Thu, 22 May 1997 15:39:46 -0700 (PDT) Received: from starfire.mn.org (root@starfire.skypoint.net [199.86.32.187]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA13806 for ; Thu, 22 May 1997 15:39:33 -0700 (PDT) Received: (from john@localhost) by starfire.mn.org (8.8.5/1.1) id RAA08514; Thu, 22 May 1997 17:38:56 -0500 (CDT) Message-ID: 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 References: <3384C34D.23AD@dal.net> X-Mailer: Mutt 0.53 Mime-Version: 1.0 In-Reply-To: <3384C34D.23AD@dal.net>; from Cabal95 on May 22, 1997 15:06:05 -0700 Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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