On Wed, Jan 15, 2014, Tayade, Nilesh wrote:
>
>
> Thanks for your suggestions. I did try capturing the debug information and
> below is how the state of the locks is. The array per lock stores information
> of the owner, file and lock_present i.e. lock is held or not.
> I see that the lock # 18 is held but when thread 19 was waiting, it was
> trying for lock # 19. Not sure what's going on.
>
> (gdb) p ssl_locks[18]
> $22 = {
> thread_id = 140003803043584,
> file_name = "md_rand.c", '\000' <repeats 30 times>,
> file_name_len = 9,
> line = 384,
> lock_present = 1
> }
> (gdb) p ssl_locks[19]
> $23 = {
> thread_id = 140003803043584,
> file_name = "md_rand.c", '\000' <repeats 30 times>,
> file_name_len = 9,
> line = 389,
> lock_present = 0
> }
>
>
By that I'm assuming it has acquired lock 18 and is attempting to get 19 but
failing because another thread already has it?
If so you need to know which thread has lock 19 and why it hasn't released it.
One way to do that is to store the details of each lock in a static array.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
