site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Thread-index: Acrc6tSNp4VmDxpv00SS+Z+szqJgow== Thread-topic: Crash with FD_SET when there are more than 1024 open files User-agent: Microsoft-Entourage/12.23.0.091001 on 4/15/10 12:04 PM, darwin-dev-request@lists.apple.com at darwin-dev-request@lists.apple.com wrote:

Message: 2 Date: Thu, 15 Apr 2010 17:54:03 +0200 From: lists@haller-berlin.de (Stefan Haller) Subject: Crash with FD_SET when there are more than 1024 open files To: darwin-dev@lists.apple.com Message-ID: <1jh00i6.c1efku18ojrlsM%lists@haller-berlin.de>

We are investigating a reproducible crash that happens in Bonjour code when we have many files open. The crash happens in DNSServiceProcessResult (part of mDNSResponder), which contains the following code:

static int more_bytes(dnssd_sock_t sd) { struct timeval tv = { 0, 0 }; fd_set readfds; FD_ZERO(&readfds); FD_SET(sd, &readfds); return(select(sd+1, &readfds, (fd_set*)NULL, (fd_set*)NULL, &tv) > 0); }

If sd is greater than 1024, bad things happen; in particular, if sd happens to be 1669, you get an immediate crash on return from the function because the code overwrites the saved ebp register.

See also <rdar://problem/7701369> to which I attached a small example program that demonstrates the crash.

Now, this makes me wonder whether it is ever possible, for any application, to exceed the number of 1024 open files. Even if Apple fixes that particular piece of code (for example by defining FD_SETSIZE to a greater value before including <sys/types.h>), other code which we can't control could have the same problem. That could be OS code, third-party libraries that we link against, plugins that we load.

One possible workaround would be to somehow ensure that there's always a free range of file descriptors below 1024 available for code other than ours. I wouldn't know how to do that though; any suggestions?

(We made a quick test to open a hundred dummy files before opening our real files, and close them right before calling the offending OS function, in the hope that that the Bonjour code would then use these; this didn't help though.)

Thanks, Stefan

-- Stefan Haller Berlin, Germany http://www.haller-berlin.de/

It seems you have a few alternatives: recompile with a larger value for FD_SETSIZE check that sd+1 is <= FD_SETSIZE before calling select(), although that isn't particularly helpful.... use poll() instead of select() Interestingly, under 10.6, the man page for select() says: Compatibility select() now returns with errno set to EINVAL when nfds is greater than FD_SETSIZE. Use a smaller value for nfds or compile with -D_DARWIN_UNLIMITED_SELECT. So I have to ask - what version of Mac OS X are you on? We ran into this problem a while ago, our solution was to avoid select(). Stuart _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com