On Mon, 2006-06-26 at 03:00 -0700, Kyle Hamilton wrote: > Does changing the quota of file descriptors available to the program > modify its behavior? 'ulimit -n -H' should give you your maximum > number allowed. Made it more from the start. Set at 100000.
> Also, your system may have a limit on the number of open sockets to > /dev/random. Well the app segfaults when I make a single connection to one of the 1500 listening sockets. So only one thread will open /dev/random to create the session ID and segfaults right there. > What's your operating system? Gentoo 2.6.15-gentoo-r5 for dual xeon box and Ubuntu Breezy on AMD Sempron. Both has 1GB RAM. > > -Kyle H > > On 6/26/06, Leon <[EMAIL PROTECTED]> wrote: > > Thanks for your reply! > > > > > Some days back, we had a riot on "select" call usage. You may revisit > > > those > > > posts to see if it is helpful. > > Well, I do not think it is select() since it works for a 1000 threads. > > The part that fails is also part of the standard OpenSSL code so I would > > not like to change it unless an explicit error is found. > > > > > One thing I do not get is: "Each thread has it's own SSL context ". > > Yes I setup the SSL_CTX in each thread. I have also taken it out of the > > threads into main() creating one global context BUT this gives the same > > error. > > > > > Therefore, I think creating as many SSL contexts as many threads are there > > > is an issue. > > Exactly - what is the issue? If a 1000 threads work why not 1500? > > > > Both machines have 1GB RAM and running Gentoo 2.5.15 (xeon) and Ubuntu > > Breezy (Sempron). > > > > Cheers > > Leon > > > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] Behalf Of Leon > > > Sent: Monday, June 26, 2006 12:19 PM > > > To: openssl-users@openssl.org > > > Subject: OpenSSL and multiple threads > > > > > > > > > Hi, > > > > > > I wrote a server app to use multiple threads. Each thread has it's own > > > SSL context and perform all the socket (socket,accept) and SSL > > > (SSL_accept) tasks. I implemented the dynamic lock mechanism for multi > > > thread support. > > > > > > I can start the server with the 1000 threads (one for each required > > > port) that we need, but found that it fails if I try 1500. Now I am > > > afraid that the 1000 threads may also become unstable with continuous > > > use. This failure occurs when all the threads are listening and I open a > > > single connection to one of them. That is: there is no load. > > > > > > I tracked the bug with gdb and found that it fails in RAND_poll(), > > > called from SSL_accept(), when a new session key is generated. The > > > strange thing is that after the file descriptor set is zeroed > > > [(FD_ZERO(&fset)] the call [FDSET(fd,&fset)] to add the random device's > > > file descriptor does not work. The set remains zeroed and once the > > > select() has executed using this set, most of the parameters including > > > the random devices file descriptor, becomes zeroed (NULL). > > > > > > It looks as if something is overrunning my stack - any ideas as to how > > > to get the sucker? I had the same results on a dual xeon as well as a > > > Athlon box. Using 0.9.7e. > > > > > > Please ignore the design - it is suppose to be experimental. > > > > > > Thanks > > > Leon > > > > > > > > > ______________________________________________________________________ > > > OpenSSL Project http://www.openssl.org > > > User Support Mailing List openssl-users@openssl.org > > > Automated List Manager [EMAIL PROTECTED] > > > > > > > > > DISCLAIMER > > > ========== > > > This e-mail may contain privileged and confidential information which is > > > the property of Persistent Systems Pvt. Ltd. It is intended only for the > > > use of the individual or entity to which it is addressed. If you are not > > > the intended recipient, you are not authorized to read, retain, copy, > > > print, distribute or use this message. If you have received this > > > communication in error, please notify the sender and delete all copies of > > > this message. Persistent Systems Pvt. Ltd. does not accept any liability > > > for virus infected mails. > > > ______________________________________________________________________ > > > OpenSSL Project http://www.openssl.org > > > User Support Mailing List openssl-users@openssl.org > > > Automated List Manager [EMAIL PROTECTED] > > > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > > User Support Mailing List openssl-users@openssl.org > > Automated List Manager [EMAIL PROTECTED] > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
