Ahoy the list. I'm seeing a memory leak using openssl 0.9.8h (0x0090808f 28
May 2008) on Solaris 5.10 from calling SSL_connect() and am trying to nail
down the cause. I'm sure it's a PEBKAC error, but can't spot it.
The leak was identified by watching the process memory use rise during
multiple reconnects to a server, then trussing and (programatically)
matching all allocations - including CRYPTO_ - to their associated frees.
Everything is just peachy unless and until I call SSL_connect(), then I get
86372 bytes leaked per call, and can't find the combination of calls to make
to get it freed. Anything up to SSL_connect() is fine, and nothing is
required after calling it in order to see the leak.
I've isolated the behaviour in a sample client, represented by the following
code fragment. I run round a couple of times to get a steady state, then
truss one iteration of the loop and analyse the truss output. Error
checking has been elided (here) for brevity: everything works as expected
and returns the expected results. The SSL->references == 1 all the way from
SSL_new() to SSL_free() then goes to 0 after SSL_free(). I'll stress again
that with the call to SSL_connect() removed, the process is leak free, with
it added (and nothing else changed), it leaks the same amount every time.
CODE:
SSL_load_error_strings();
SSL_library_init();
RAND_load_file("/dev/urandom", 1024);
ssl_context = SSL_CTX_new(TLSv1_client_method());
SSL_CTX_set_verify(ssl_context, SSL_VERIFY_PEER, NULL);
SSL_CTX_set_verify_depth(ssl_context, 2);
SSL_CTX_set_options(ssl_context, SSL_OP_ALL|SSL_OP_NO_SSLv2);
SSL_CTX_load_verify_locations(ssl_context, ca_certificate, NULL);
while(1)
{
theSSL = SSL_new(ssl_context);
int s = socket(PF_INET, SOCK_STREAM, 0);
int on = 1; /* Turn off Nagle */
setsockopt(s, IPPROTO_TCP, TCP_NODELAY, (void *)&on, sizeof(on));
connect(s, (struct sockaddr *)&sin, sizeof sin);
theBIO = BIO_new_socket(s, 0);
SSL_set_bio(theSSL, theBIO, theBIO);
/* This line causes the leak. With it commented out, everything is
fine. */
SSL_connect(theSSL);
/* Here's what I've tried to persuade the memory to free. The same
* behaviour is seen with all, some or none of these calls present.
*/
/* If I make this a while(0 == shutdown) loop, SSL_shutdown() returns
* 0 indefinitely - is this my problem? */
int shutdown = SSL_shutdown(theSSL);
if(0 == shutdown) /* as recommended, call again */
shutdown = SSL_shutdown(theSSL);
/* Tried this, didn't help */
SSL_set_shutdown(theSSL, SSL_SENT_SHUTDOWN);
/* ...neither did this */
SSL_set_shutdown(theSSL, SSL_RECEIVED_SHUTDOWN);
/* ... still no luck... */
SSL_clear(theSSL);
BIO_free(theBIO);
close(s);
/* Frees everything except 86372 bytes */
SSL_free(theSSL);
printf("********** Run complete - hit a key to continue
**********\n");
(void)fgetc(stdin);
} // while(1)
A representation of the story from truss. Some interesting stuff is at the
start -
note that calling SSL_connect() appears to cause the SSL and BIO structures
to
leak, even though the SSL reference count goes to 0 after SSL_free().
Address 0x143f60 (1326944) of size 0x108 (264) at truss line 8, call stack:
SSL_new(0x134c10, 0x0, 0x92cec, 0xff131298)
Address 0x143650 (1324624) of size 0x20 (32) at truss line 21, call stack:
SSL_new(0x134c10, 0x0, 0x92cec, 0xff131298)
X509_VERIFY_PARAM_new(0x143ffc, 0x0, 0x0, 0x0)
Address 0x1447b8 (1329080) of size 0x40 (64) at truss line 122, call stack:
BIO_new_socket(0x4, 0x0, 0x0, 0x1326de)
BIO_new(0x12c294, 0x0, 0x0, 0x0)
Address 0x153670 (1390192) of size 0x490a (18698) at truss line 314, call
stack:
ssl3_connect(0x143f60, 0x5000, 0x122354, 0x122354)
ssl3_setup_buffers(0x143f60, 0x4000, 0x4000, 0x0)
Address 0x144ce8 (1330408) of size 0xc (12) at truss line 295, call stack:
ssl3_connect(0x143f60, 0x5000, 0x122354, 0x122354)
BUF_MEM_new(0x1, 0x4000, 0xfc00, 0x1445b4)
Address 0x15b630 (1422896) of size 0xc8 (200) at truss line 411, call stack:
ssl3_connect(0x143f60, 0x5000, 0x122354, 0x122354)
ssl3_client_hello(0x143f60, 0x15b5c0, 0x1100, 0x1110)
ssl_get_new_session(0x143f60, 0x0, 0x0, 0x0)
SSL_SESSION_new(0x0, 0x0, 0x0, 0x0)
Address 0x15a040 (1417280) of size 0x8 (8) at truss line 1203, call stack:
ssl3_connect(0x143f60, 0x5000, 0x122354, 0x122354)
ssl3_get_server_certificate(0x143f60, 0x123880, 0x1100, 0x0)
ASN1_item_d2i(0x0, 0xffbffa60, 0x3cd, 0xf2c74)
ASN1_item_ex_d2i(0xffbff9f4, 0xffbffa60, 0x3cd, 0xf2c74)
asn1_item_ex_combine_new(0xffbff9f4, 0xf2c74, 0x0, 0xffbff966)
asn1_item_ex_combine_new(0x15b704, 0xf87b8, 0x0, 0x4)
Address 0x15b168 (1421672) of size 0x10 (16) at truss line 1756, call stack:
ssl3_connect(0x143f60, 0x5000, 0x122354, 0x122354)
ssl3_get_server_certificate(0x143f60, 0x123880, 0x1100, 0x0)
ASN1_item_d2i(0x0, 0xffbffa60, 0x3cd, 0xf2c74)
ASN1_item_ex_d2i(0xffbff9f4, 0xffbffa60, 0x3cd, 0xf2c74)
asn1_template_noexp_d2i(0x15b700, 0xffbff96c, 0x3c9, 0xf2c38)
ASN1_item_ex_d2i(0x15b700, 0xffbff804, 0x3c9, 0xf2c04)
asn1_template_noexp_d2i(0x137c7c, 0xffbff77c, 0x31a, 0xf2b78)
ASN1_item_ex_d2i(0x137c7c, 0xffbff614, 0x31a, 0xf2b14)
x509_name_ex_d2i(0x137c7c, 0xffbff614, 0x31a, 0xf2b14)
asn1_template_noexp_d2i(0xffbff420, 0xffbff424, 0x31a, 0xf2acc)
asn1_template_noexp_d2i(0xffbff3a4, 0xffbff3ac, 0x8c, 0xf2a9c)
ASN1_item_ex_d2i(0xffbff31c, 0xffbff324, 0x16, 0xf2a80)
asn1_item_ex_combine_new(0xffbff31c, 0xf2a80, 0x0, 0xffbff296)
[...] dozens more ssl3_connect(), mostly ssl3_get_server_certificate() leaks
elided
Kind regards,
-Colin MacDonald-
--
View this message in context:
http://old.nabble.com/SSL_connect%28%29-in-0.9.8h---memory-leak%2C-or-user-error--tp33544735p33544735.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [email protected]
