RE: SSL_write() crashes
Mikhail Kruk
> I've never really dealt with signals before, but I will definitely look into
> it. Thanks for the heads up. Any idea if there is a way to circumvent this
> in a cross-platform nature?
#if defined(unix)
{struct sigaction act;
act.sa_handler = SIG_IGN;
sigemptyset (&act.sa_mask);
act.sa_flags = 0;
sigaction (SIGPIPE, &act, NULL);}
#endif
>
> Dusty
>
> -----Original Message-----
> From: owner-ope...@openssl.org
> [mailto:owner-ope...@openssl.org] On Behalf Of Kyle Hamilton
> Sent: Wednesday, February 22, 2006 4:31 PM
> To: openss...@openssl.org
> Subject: Re: SSL_write() crashes
>
> Chances are, you received a SIGPIPE. If not caught, that's a fatal
> signal. (SIGPIPE occurs when you try to write to a socket that has
> been closed by the other end.)
>
> -Kyle H
>
> On 2/22/06, Dusty Hendrickson <dhendr...@cleversafe.com> wrote:
>> We currently have an SSL client/server setup that uses a basic "send
>> request, receive response" architecture. In one scenario, we did
> something
>> similar to the following:
>>
>> -----------------------------
>> Client:
>>
>> 1. Send request
>> 2. Delete connection
>>
>> Server:
>>
>> 1. Wait for connection
>> 2. Process request
>> 3. Send response
>> -----------------------------
>>
>> The issue here was that the client never tried to receive a response
> (since
>> it was unnecessary) and simply deleted the connection. However, the
> server
>> was trying to send a response, even though the client closed the
> connection.
>> We expected the SSL_write() function to handle such a scenario, returning
> an
>> error code or something similar. However, it simply crashed. The last
> line
>> of code that executes is the following:
>>
>>
>> int ret = SSL_write( ssl, &buffer[ bytesWritten ], length - bytesWritten
> );
>>
>>
>> We know that bytesWritten is within the bounds of the 'buffer' array and
>> that 'length - bytesWritten' is always greater than 0. Therefore we
> believe
>> the issue to be with SSL_write() itself. We are using OpenSSL 0.9.8.
>> Anyone ever run into something like this, or have any ideas on what might
> be
>> happening? Any suggestions would be appreciated. Thanks
>>
>> Dusty
>>
>> ______________________________________________________________________
>> OpenSSL Project http://www.openssl.org
>> User Support Mailing List openss...@openssl.org
>> Automated List Manager majo...@openssl.org
>>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openss...@openssl.org
> Automated List Manager majo...@openssl.org
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openss...@openssl.org
> Automated List Manager majo...@openssl.org
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Kyle Hamilton
thread-safe, sigaction() is.
These will work on POSIX environments. I believe Windows doesn't send
a signal, but rather returns an error with WSAGetLastError() returning
"ECONNRESET" or something like that.
The easiest way to handle it in a single-threaded environment is:
#include <signal.h>
signal(SIGPIPE, SIG_IGN);
-Kyle H
On 2/22/06, Dusty Hendrickson <dhendr...@cleversafe.com> wrote:
> I've never really dealt with signals before, but I will definitely look i=
nto
> it. Thanks for the heads up. Any idea if there is a way to circumvent t=
his
> in a cross-platform nature?
> > We expected the SSL_write() function to handle such a scenario, returni=
ng
> an
> > error code or something similar. However, it simply crashed. The last
> line
> > of code that executes is the following:
> >
> >
> > int ret =3D SSL_write( ssl, &buffer[ bytesWritten ], length - bytesWrit=
ten
> );
> >
> >
> > We know that bytesWritten is within the bounds of the 'buffer' array an=
d
> > that 'length - bytesWritten' is always greater than 0. Therefore we
> believe
> > the issue to be with SSL_write() itself. We are using OpenSSL 0.9.8.
> > Anyone ever run into something like this, or have any ideas on what mig=