Re: Socket left in CLOSE_WAIT state...
According to the doc:
0 indicates the ssl_shutdown function needs to be called again.
1 indicates success
-1 indicates failure
if r = ssl_shutdown() == -1
// failure
if r == 0
r = ssl_shutdown
if r == < 1
// failure
else
//success
Stuart
- Original Message
From: Matthew Allen
To: openssl-users@openssl.org
Sent: Wed, April 21, 2010 4:00:10 PM
Subject: Re: Socket left in CLOSE_WAIT state...
-- Original Message --
To: (openssl-users@openssl.org)
From: Stuart Weatherby (stuart_weathe...@yahoo.ca)
Subject: Re: Socket left in CLOSE_WAIT state...
Date: 22/4/2010 5:18:48a
> Shutdown disables the ability to read, write (or both) on a
> socket. However, shutdown() does not close the socket. to release the
> socket descriptor back to the OS you also need to call closesocket();
This code does want I want:
int r = 0;
if ((r = SSL_shutdown(Ssl)) >= 0)
{
closesocket(SSL_get_fd(Ssl));
}
But it seems like an ugly hack. It _should_ close the socket by itself. I'm
worried that this leakes some BIO object(s), because clearly if the BIO objects
were free'd they'd close their SOCKET. And since that ISN'T happening maybe the
BIO object is not being free [correctly].
> Saju Paul wrote:
> Looks like it needs a BIO_free_all(bio) or something similair.
I tried that before and after the SSL_shutdown call and it just crashes,
clearly thats not the "proper" way. Maybe there is a way to disassociate the
BIO from the SSL but it seems like a hack rather than a solution.
Thanks for the responses.
PS in investigating these issues I did try and download + build OpenSSL 1.0.0
for myself, hoping to step into the code and see where things went, but after
following the instructions to build with Visual C++ I got stuck running a
command that never finished. The perl "do_ms" thing would run for hours using
up 100% of the core it was running on and just never seem to finish. Ended up
killing it and posting on the mailing list instead. Just FYI.
--
Matthew Allen
http://www.memecode.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Socket left in CLOSE_WAIT state...
Shutdown disables the ability to read, write (or both) on a socket. However,
shutdown() does not close the socket. to release the socket descriptor back to
the OS you also need to call closesocket();
- Original Message
From: Matthew Allen
To: openssl-users@openssl.org
Sent: Wed, April 21, 2010 2:18:27 AM
Subject: Socket left in CLOSE_WAIT state...
Hi,
My code leaves sockets in the CLOSE_WAIT state after I free the SSL connection
(running on windows XP with OpenSSL 0.9.8e). After I'm done with the
connection I call SSL_shutdown and SSL_free, but that doesn't close the socket
on the client side. My code's probably wrong, so tell me what I should change?
#include
#include "windows.h"
#include "openssl/ssl.h"
char Hostname[] = "imap.gmail.com";
int Port = 993;
int main(int args, char **arg)
{
printf("OpenSSL Test\n");
SSL_library_init();
SSL_load_error_strings();
ERR_load_BIO_strings();
OpenSSL_add_all_algorithms();
SSL_CTX *Ctx = SSL_CTX_new(SSLv23_client_method());
if (Ctx)
{
SSL *Ssl = 0;
BIO *Bio = BIO_new_ssl_connect(Ctx);
if (Bio)
{
BIO_get_ssl(Bio, &Ssl);
if (Ssl)
{
SSL_set_mode(Ssl, SSL_MODE_AUTO_RETRY);
BIO_set_conn_hostname(Bio, Hostname);
BIO_set_conn_int_port(Bio, &Port);
if (BIO_do_connect(Bio) > 0)
{
printf("Connected to '%s' using SSL\n", Hostname);
char Data[256];
char *Cmd = "A0001 CAPABILITY\r\n";
int w = SSL_write(Ssl, Cmd, strlen(Cmd));
if (w > 0)
{
printf("Wrote %i bytes.\n", w);
int r = SSL_read(Ssl, Data, sizeof(Data));
if (r > 0)
{
printf("Got %i bytes.\n", r);
}
else printf("SSL_read failed.\n");
}
else printf("SSL_write failed.\n");
}
else printf("BIO_do_connect failed.\n");
}
else printf("BIO_get_ssl failed.\n");
}
else printf("BIO_new_ssl_connect failed.\n");
if (Ssl)
{
SSL_shutdown(Ssl);
SSL_free(Ssl);
}
/* At this point I expect the socket should have disappeared, but it's
still there
hanging around in CLOSE_WAIT... why? */
SSL_CTX_free(Ctx);
}
return 0;
}
Thanks
--
Matthew Allen
__
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: possible user error / memory leak using RSA_new() and RSA_free();
Steve & Mounir, Thanks a lot for answering my questions. Stuart - Original Message From: Dr. Stephen Henson To: openssl-users@openssl.org Sent: Mon, April 19, 2010 4:38:14 PM Subject: Re: possible user error / memory leak using RSA_new() and RSA_free(); On Mon, Apr 19, 2010, Stuart Weatherby wrote: > Thanks Steve, > > After commenting out lines 24 & 25 there is still unfree'd memory: > http://www.openssl.org/support/faq.html#PROG13 Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Projecthttp://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible user error / memory leak using RSA_new() and RSA_free();
Thanks Steve,
After commenting out lines 24 & 25 there is still unfree'd memory:
Stuart
==8155== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1)
==8155== malloc/free: in use at exit: 528 bytes in 10 blocks.
==8155== malloc/free: 137 allocs, 127 frees, 13,340 bytes allocated.
==8155== For counts of detected errors, rerun with: -v
==8155== searching for pointers to 10 not-freed blocks.
==8155== checked 227,584 bytes.
==8155==
==8155== 528 bytes in 10 blocks are still reachable in loss record 1 of 1
==8155== at 0x4A05809: malloc (vg_replace_malloc.c:149)
==8155== by 0x35156DAD51: CRYPTO_malloc (in /lib64/libcrypto.so.0.9.8e)
==8155== by 0x351567EAC8: lh_new (in /lib64/libcrypto.so.0.9.8e)
==8155== by 0x351565B4C4: (within /lib64/libcrypto.so.0.9.8e)
==8155== by 0x351565B5E5: (within /lib64/libcrypto.so.0.9.8e)
==8155== by 0x351565B98A: (within /lib64/libcrypto.so.0.9.8e)
==8155== by 0x351567698F: BIO_set (in /lib64/libcrypto.so.0.9.8e)
==8155== by 0x3515676A19: BIO_new (in /lib64/libcrypto.so.0.9.8e)
==8155== by 0x351569DE71: PEM_ASN1_read (in /lib64/libcrypto.so.0.9.8e)
==8155== by 0x400836: main (rsatest.c:30)
==8155==
==8155== LEAK SUMMARY:
==8155== definitely lost: 0 bytes in 0 blocks.
==8155== possibly lost: 0 bytes in 0 blocks.
==8155== still reachable: 528 bytes in 10 blocks.
==8155== suppressed: 0 bytes in 0 blocks.
- Original Message
From: Dr. Stephen Henson
To: openssl-users@openssl.org
Sent: Mon, April 19, 2010 3:12:53 PM
Subject: Re: possible user error / memory leak using RSA_new() and RSA_free();
On Mon, Apr 19, 2010, Stuart Weatherby wrote:
> Hi List,
>
> I am trying to figure out why there is a memory leak using RSA_new & RSA_free:
> Below is a code sample (which will produce a memory leak) and the relevent
> valgrind output. I have checked the documentation but I still fail to see my
> error.
>
> As I understand the docuumentation, RSA_free() is the only required call to
> free memory allocated using the RSA_new() function.
>
> Thanks,
>
> Stuart
>
>
> int main (void)
> {
> FILE *fp;
> RSA *p = NULL;
> char *pt = "hi\0";
> char pt_0 = *pt;
> int pt_len = strlen(pt);
> unsigned char *ct;
> int ct_len = 0;
>
> if ((p = RSA_new()) == NULL)
> return 1;
> if ((fp = fopen ("pub.key", "rb")) == NULL)
> return 2;
> if ((p = PEM_read_RSA_PUBKEY(fp, NULL, NULL, NULL)) == NULL)
> {
> fclose(fp);
> return 3;
> }
> fclose(fp);
> ct = malloc(RSA_size(p));
> if(RSA_public_encrypt(pt_len,(unsigned char *) pt,ct, p,
> RSA_PKCS1_OAEP_PADDING) == -1)
> return 4;
> free(ct);
> RSA_free(p);
> return 0;
> }
>
You are allocating an RSA structure then completely overwriting the pointer
with a new one. Leaving the original as the leak.
Delete the RSA_new() call.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
possible user error / memory leak using RSA_new() and RSA_free();
Hi List,
I am trying to figure out why there is a memory leak using RSA_new & RSA_free:
Below is a code sample (which will produce a memory leak) and the relevent
valgrind output. I have checked the documentation but I still fail to see my
error.
As I understand the docuumentation, RSA_free() is the only required call to
free memory allocated using the RSA_new() function.
Thanks,
Stuart
int main (void)
{
FILE *fp;
RSA *p = NULL;
char *pt = "hi\0";
char pt_0 = *pt;
int pt_len = strlen(pt);
unsigned char *ct;
int ct_len = 0;
if ((p = RSA_new()) == NULL)
return 1;
if ((fp = fopen ("pub.key", "rb")) == NULL)
return 2;
if ((p = PEM_read_RSA_PUBKEY(fp, NULL, NULL, NULL)) == NULL)
{
fclose(fp);
return 3;
}
fclose(fp);
ct = malloc(RSA_size(p));
if(RSA_public_encrypt(pt_len,(unsigned char *) pt,ct, p,
RSA_PKCS1_OAEP_PADDING) == -1)
return 4;
free(ct);
RSA_free(p);
return 0;
}
Here is the valgrind output:
==2330== 528 bytes in 10 blocks are still reachable in loss record 2 of 2
==2330== at 0x4A05809: malloc (vg_replace_malloc.c:149)
==2330== by 0x35156DAD51: CRYPTO_malloc (in /lib64/libcrypto.so.0.9.8e)
==2330== by 0x351567EAC8: lh_new (in /lib64/libcrypto.so.0.9.8e)
==2330== by 0x351565B4C4: (within /lib64/libcrypto.so.0.9.8e)
==2330== by 0x351565B5E5: (within /lib64/libcrypto.so.0.9.8e)
==2330== by 0x351565B98A: (within /lib64/libcrypto.so.0.9.8e)
==2330== by 0x351566F9B3: RSA_new_method (in /lib64/libcrypto.so.0.9.8e)
==2330== by 0x40083D: main (rsatest.c:24)
==2330==
==2330== LEAK SUMMARY:
==2330== definitely lost: 168 bytes in 1 blocks.
==2330== possibly lost: 0 bytes in 0 blocks.
==2330== still reachable: 528 bytes in 10 blocks.
==2330== suppressed: 0 bytes in 0 blocks.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
