Hi,

My client application tries to establish SSL connection as shown below:

//

    err = SSL_connect (ssl);
    l_ssl_err_code=SSL_get_error(ssl, err);


    struct timeval l_connect_timeout;

    l_connect_timeout.tv_usec=0;
    l_connect_timeout.tv_sec=time_remaining;
    //time remaining is calculated by application. The SSL connect , data
exchange should happen within stipulated time.

    while(1)
    {
        if(err == -1)
        {
            if(l_ssl_err_code == SSL_ERROR_WANT_READ || l_ssl_err_code ==
SSL_ERROR_WANT_WRITE)
            {
                l_fds=select(sd+1, &filedes_set,NULL,NULL,
&l_connect_timeout);
                if(l_fds == 0)
                {
                  //select timed out  ..This does happen under stress test
and server is slow in its response.
                  return 0;
                }

                else if(l_fds < 0)
                {
                    //select failed
                    return 0;
                }
                else
                {
                    if(FD_ISSET(sd,&filedes_set))
                    {
                        err = SSL_connect (ssl);
                         l_ssl_err_code=SSL_get_error(ssl, err);
                }
            }
            else
            {
                //handshake failure
                //check the status of l_ssl_err_code
                return 0;
            }
        }
        else if(err == 0)
        {
            //handshake failure
            //check the status of l_ssl_err_code
            return 0;
        }

        else if(err == 1)
        {
            //SSL handshake succesful.
        }

    }//end of while

    One constraint is that the SSL connect , data exchange should happen
within stipulated time.As such
    when my client is under stress with hundreds of threads trying to
connect to server, the select may timeout and return
    with out completing the handshake.

    In such scenarios is it appripriate to call methods like SSL_read()
,SSL_shutdown().
    Currently my application tries SSL_shutdown() even after select times
out in SSL handshake phase. Under stress, the application   aborts. The
stack in core dumps is not consistent.

    #0  0x40000402 in __kernel_vsyscall ()
    #1  0x00b7b1f8 in raise () from /lib/libc.so.6
    #2  0x00b7c948 in abort () from /lib/libc.so.6
    #3  0x00bb052a in __libc_message () from /lib/libc.so.6
    #4  0x00bb6424 in _int_free () from /lib/libc.so.6
    #5  0x00bb695f in free () from /lib/libc.so.6
    #6  0x4057477a in CRYPTO_free (str=0x8e96090) at mem.c:378
    #7  0x405dfc5c in x509_name_ex_d2i (val=0x22e, in=0x0, len=0,
it=0x405e65cf, tag=149510012, aclass=2021933032, opt=0 '\0',
        ctx=0x4064197c) at x_name.c:194
    #8  0x08f1d13d in ?? ()
    #9  0x08e95688 in ?? ()
    #10 0x08e96090 in ?? ()
    #11 0x40641964 in X509_NAME_INTERNAL_it () from
../lib/libcrypto.so.0.9.8
    #12 0x0000022e in ?? ()
    Previous frame inner to this frame (corrupt stack?)


     Is it due to calling methods like SSL_shutdown() in cases where
SSL_handshake process was terminated abruptly.

    Thanks,
    Prabhu. S

Reply via email to