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