[omniORB] omnithread memory leak

[Sai-Lai Lo]

>>>>> Carlson, Andy writes:

> Another problem I found while torturing my code at high levels
> of concurrent connections...

> omniORB 2.7.1, posix threads, solaris2.6...

> posix.cc line 541...

> If pthread_create fails (in my case it returns EAGAIN), an
> omni_thread_fatal exception is thrown. Unfortunately this 
> means that the pthread_attr_destroy call is not made and 
> the pthread_attr_t leaks.

> I'm not sure if omni_thread_fatal means that 'all bets are off'
> or whether omniThread is supposed to cope with this situation
> - EAGAIN from pthread_create is not an unrecoverable error.

Indeed there is a memory leak. Will plug the leak later. As you may have
guessed, omni_thread_fatal was intended to mean 'all bets are off'. This is
the lowest common denominator. For platforms that are known to handle
resource exhaustion gracefully, we can add code to deal with the situation
better.

> BTW, this is occurring with about 70 threads in existence, 50
> of which are tying up Solaris LWPs. Anyone know how to ask
> Solaris to allow more LWP's?

On a Solaris 2.5.1 machine, I can do way beyond this limit (over a hundred
before I stop trying). On a solaris 2.7 machine running the same binary
(i.e. compiled for 2.5.1), I see the same behaviour as you do plus some
error message from the thread library about resource exhaustion. I wonder if
this is a runtime library limitation or a bug or simply an OS/kernel
configuration option. I don't know if there is an API to adjust this limit.

Sai-Lai


-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND