-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Michael,
On 7/18/16 10:10 AM, Christopher Schultz wrote: > Michael, > > On 7/18/16 8:53 AM, Michael Diener wrote: >> On 6 July 2016 at 00:09, Christopher Schultz >> <ch...@christopherschultz.net> wrote: > >>>> From what I understand a buffer overflow would only happen >>>> for FD_SET if the fd_set gets over 1024 descriptors. I made >>>> sure that my ulimit for open files is set and applied large >>>> enough, so that's not it. >>> >>> There's nothing magic about the ulimit. An fd_set should size >>> appropriately for your OS. On my Linux system, FD_SETSIZE >>> happens to be set to 1024. Reading through the byzantine >>> labyrinth of includes, it appears that FD_SET has zero >>> boundary-checking, so it's therefore possible that overflow >>> will occur. > > >> Regarding the FD_SETSIZE, it is also set for me to 1024 although >> the ulimit is set higher. > > Well, the FD_SETSIZE is just the maximum size of the fd set that > can be passed-into select() specifically. That doesn't limit the > number of file descriptors your processes can open. The ulimit > settings are the limits on those. > >> I'm a bit lost now on what I should do now. What makes me wonder >> is, that nobody else seems to hit this limitation of FD_SET and >> this makes me think something on my Linux machine is not right. > > Well, not everyone is using the same setup. For example, using NIO > through Java is likely to get you the poll() call under the hood, > so supporting more than e.g. 1024 file descriptors is not an issue > there. That's just a guess, but I think it's a reasonable guess. > > I think tcnative+APR is not widely deployed. I have no numbers to > back that up, but we don't get a huge volume of questions in the > list about i t. > >> What would you guys suggest? Should I file a bug report? My >> system runs stable now after the change to poll() and I don't hit >> that problem anymore. > > You should absolutely file the bug report and attach your patch to > it. Thanks for your great analysis and a proposed patch. Oh, it's worth pointing-out that while poll() is part of the POSIX.1-2001, not all supported platforms also support that standard. So we'll probably need to have a fallback mode that uses select() instead of poll() when poll() isn't available. That probably also means that we need to detect the unavailability of poll() and (a) issue a warning to the logger and (b) write-down the maximum size of that fd-array to avoid the buffer overflow. (Or, add better checking when select() is in use... we must always ensure that the "sd" local in nb_connect does not exceed FD_SIZE + 1.) In fact, I'll make that fix right now. Finally, poll() has a few versions, some of which allow e.g. -1 to be used in the array to mean "ignore this fd" while others do not. That means that, on some platforms, we'll need to be very careful about the management of that fd array, possibly re-sizing it, etc. when necessary. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJXjOnAAAoJEBzwKT+lPKRYKQcP/RwOPb7Jm0w2kEDI+2DAhlHS +hho+yR9N/CfoK73Zo1PDDc/MLT69SFbkrP4jUtAWL3r9mzzpTfn5IuLuY/XxDjE 2hZdLpu3tG8NFjgZ9i1Z4fauAifMS7WVnyWH2oFWP37BF2s3d8ZeAWWdfsgrVPBJ ojNc3hsDPpJb3DGbRMgEVs43SfRNoKLvTCotlcRozadDDi/pAcoMft1IpOPnwh77 Sr9e17YiFCIJvOmqw57ljfbeWLeFTH3kbmDQSNNbiSdZ9ZKrTXBJOyVCxPvZW3uu uz5/GIWhmHyjSIEC3TiQKgt8DFLkcfZDU7LUD2gYPyRsmKw0KwEFl8pPBQJWST98 lV3xUODfr1KcM2rmNoisnIPsVUrDH7biu/qGYPqPBeWxwuJhgwrYwTExmkmpbcce 1IRk+5P/DvZHYn9LVBcNIb+sE5TroMeCxSB+rt6kN6L0kPX1Zar97Qels2Xd5VVp g650gOuNcgJAXJyJx/y3/7oe/GJKdscbY+W23JhMp1gWEdGbrf8Ki6WogOEcfNPR Bj+DxpINJfYqCpqE1GluF7s0eou/ybaFzmanIwHzV2xCezA06VJ7GtzJgvwbuSq4 dbf05eV4TNvq7BRZ+nuT3UKB6Ds824Kfmc0fPy9AimIdmuqlgoB1nR6ZLromuweV 7glBmIsnBXO+ZomoItxT =Oet1 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
