[Ace-users] [ace-users] ACE non-blocking SSL SOCK_Acceptor and FD_SETSIZE..bug? (both 5.5 and 5.6.1)

Matthew Gillen mgillen at bbn.com
Tue Jan 8 20:53:10 CST 2008

Steve Huston wrote:
>> It appears to be a known issue that using
>> select-based operations on handles greater than the FD_SETSIZE won't
>> work out, but I would expect it to return an error, not corrupt
>> nearby memory. Is this one of those "Don't do that" things, or
>> should I file a bug report form?
> This is a bug, or some level of deficiency at least, since the
> implementation assumes it can use select() on the handle value.

POSIX says that the behavior of select() in that case is undefined, which
means you won't get a recognizable error from the underlying system call (or
at best, you'll get a platform-specific error).  ACE could potentially do
some sanity checking on inputs, but that would add overhead to every
select() call.

The memory corruption probably isn't from the select() call itself, but from
using the FD_SET macro (which ACE is doing for you) with fd not in the
FD_SETSIZE range (the behavior of which is also undefined, but since the
'fd_set' type is a fixed-size buffer, you're pretty much guaranteed to stomp
on memory if you use a value outside the 0-1024 range).

Apparently in *BSD you can redefine FD_SETSIZE on a per-application basis by
defining it first, before any system #include files, but this definitely
doesn't work on linux.


More information about the Ace-users mailing list