SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN
John Unsworth
John.Unsworth at synchronoss.com
Fri May 3 09:34:14 UTC 2019
Testing changed code.
Regards
John
________________________________
From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Matt Caswell <matt at openssl.org>
Sent: Friday, May 3, 2019 10:16 am
To: openssl-users at openssl.org
Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN
CAUTION: This email originated from outside of Synchronoss.
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 SSL_get_error() is using
> the same SSL handle as the SSL_read(), which can be materially
> altered by concurrent writes. (Matt, if you're still reading this
> thread, do you agree?)
>
> I would not release the mutex until after the call to SSL_get_error().
An SSL object should not be 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 HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190503/7209280b/attachment.html>
More information about the openssl-users
mailing list