used in multiple threads at the same time no
> matter
> what the API call. This applies to SSL_get_error() as well. If you are
> doing
> that then that could most definitely cause the behaviour you are seeing.
>
> Matt
>
> -- next part --
> An
On Fri, May 03, 2019 at 09:34:14AM +, John Unsworth wrote:
> Testing changed code.
For the record, though I think you realise this, *both* the SSL_read()
or SSL_write() and the following SSL_get_error() need to be protected
as a unit by the *same* instance of the locked mutex. It would not
On 02/05/2019 18:23, Viktor Dukhovni wrote:
>>> At this point you'd be calling SSL_get_error(), is there a lock that
>>> prevents writes between SSL_read() and SSL_read() and SSL_get_error()?
>>
>> The mutex does not protect SSL_get_error() calls.
>
> I think that's an application bug. The
Testing changed code.
Regards
John
From: openssl-users on behalf of Matt
Caswell
Sent: Friday, May 3, 2019 10:16 am
To: openssl-users@openssl.org
Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN
CAUTION: This email originated from
On 03/05/2019 16:18, ramakrushna mishra wrote:
> Hi,
>
> When client(openssl) is configured with TLSv1 and Server(java) was configured
> with TLSv1_2, then in openssl version 1.1.0e we used to get the error code
> : 337002677( 0x141640B5). But with openssl 1.1.1 upgrade the error code
>
Hi,
When client(openssl) is configured with TLSv1 and Server(java) was
configured with TLSv1_2, then in openssl version 1.1.0e we used to get the
error code : 337002677( 0x141640B5). But with openssl 1.1.1 upgrade the
error code changed to 337285301
(0x141A90B5). Moreover Earlier in java also we
> On May 2, 2019, at 12:09 PM, Matt Caswell wrote:
>
>> when is the 1.1.1c expected to be released? There were plenty of bug
>> fixes committed to the 1.1.1 branch since the 1.1.1b release. Is the
>> 1.1.1c release imminent?
>
> There are no plans at the moment.
There should perhaps be a
