Yes I'm sure the build process is correct.
Turns out this problem was cause by one thread calling exit() while
another thread was doing SSL_write(). The SSL exit handler triggered by
exit() was causing the lock in question to be freed AFAIKT.
So it would seem that threads either need to exit with pthread_exit() or
return to a known state such that no SSL calls are in progress in any
thread before the process can safely exit().
On 3/1/2019 11:54 AM, Viktor Dukhovni wrote:
On Fri, Mar 01, 2019 at 11:16:52AM -0800, Norm Green wrote:
[ Please avoid non-breaking spaces in your posts. ]
I'm debugging a failure in a debug build on Solaris SPARC in the below
code in rand_lib.c. On line 744, rand_meth_lock is NULL, which suggests
the RUN_ONCE code is not working. Wondering if anyone else has seen
this problem?
We did not see this issue in 1.1.1a. Perhaps changes in the RUN_ONCE
code in this commit are responsible?
https://github.com/openssl/openssl/commit/f725fe5b4b6504df08e30f5194d321c3025e2336
That PR looks correct, and has no effect on the behaviour of RUN_ONCE
below. It only introduces RUN_ONCE_ALT() and uses it in a few
special cases.
741 if (!RUN_ONCE(&rand_init, do_rand_init))
742 return NULL;
743
744 CRYPTO_THREAD_write_lock(rand_meth_lock);
Are you sure you're compiling linking and running with the desired
set of headers and libraries?
