1.1.1b crash (RUN_ONCE problem?)
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?
> 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;
>> 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