Hi David, Yes, the design of one thread per connection is bit odd. Our application is used to test a SSL server for its performance. The application would simulate hundreds of client and at a time try connecting to the server. The server would be thus tested for burst connection handling capability. One thread for each client made sense in that case.
And the stack size is set to 1 MB. pthread_attr_setstacksize(&attr, 1024*1000) I should check if setting this less would have any other impact. Thanks & Regards, Prabhu. S On 10/15/07, David Schwartz <[EMAIL PROTECTED]> wrote: > > > > The application creates about 800 threads in a Linux 2.6 Kernel. > > This is really one of those "don't do that then" things. > Thread-per-connection is well-known to break down at about 750 > connections. > > > #0 SHA1_Init (c=0x0) at sha_locl.h:150 > > #1 0x405b2bb0 in init (ctx=0x0) at m_sha1.c:72 > > #2 0x405afc91 in EVP_DigestInit_ex (ctx=0x4d606230, > > type=0x4061f620, impl=0x0) at digest.c:207 > > #3 0x405ac08e in ssleay_rand_add (buf=0x0, num=0, > > add= 2.5863007356866632e-306) at md_rand.c:263 > > #4 0x405ace6e in RAND_add (buf=0x8a269f8, > > num=144861688, entropy=0) at rand_lib.c:151 > > It looks like OpenSSL doesn't properly check for an out-of-memory > condition > in this code path. However, the main problem is that you ran out of > virtual > memory. > > It may help to reduce the stack size for each thread. But you really > should > re-architect. Thread-per-connection is a brain dead approach for any > server > that has to handle hundreds of connections. > > DS > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] >
