> On Mar 4, 2019, at 11:29 PM, Norm Green wrote:
>
> 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
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 wi
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.
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
