1.1.1b crash (RUN_ONCE problem?)

Norm Green norm.green at gemtalksystems.com
Tue Mar 5 04:29:28 UTC 2019

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?

More information about the openssl-users mailing list