Crash with FD_SET when there are more than 1024 open files
site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=haller-berlin.de; s=mail_2009081900; h=Message-ID:Date:From:Subject:To; bh=cLQudhqrUFjgewpheXTJKaLJi9QHTPIebDBtYf9Gzi4=; b=rPcQfwjTtwQsg8QjLx1WN/KiTs2ne4OLwKnTrB9OlkDaZHA6V9vabd9UtKLmPZBI7d9Ahc/lnrPRE063wxuxp4yMGQo+auD8aGS7MdglfVrjIUJktINSLe0AfcbIVdWt31mZJdpVfUpVuAbcfjq5+MDtw+hYfvwGYVkXcCBWa2w=; User-agent: MacSOUP/2.8.3 (Mac OS X version 10.6.3 (x86)) 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/ _______________________________________________ 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
participants (1)
-
lists@haller-berlin.de