[ https://issues.apache.org/jira/browse/TS-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14259542#comment-14259542 ]
Susan Hinrichs commented on TS-3261: ------------------------------------ I think I duplicated [~sudheerv]'s experiment. I applied the first part of his patch, and then added another call to assert that the rbio and wbio's are NULL after a SSL_new. I ran some traffic through and the asserts did not go off. I think this logic is pretty deterministic, so some basic traffic should verify the concept. Here is the patch I ran. Of course, you wouldn't really want the NULL asserts in production.. I just put them in for my own test/verification. diff --git a/iocore/net/SSLInternal.cc b/iocore/net/SSLInternal.cc index d2c96fe..3a2f504 100644 --- a/iocore/net/SSLInternal.cc +++ b/iocore/net/SSLInternal.cc @@ -32,5 +32,15 @@ void SSL_set_rbio(SSLNetVConnection *sslvc, BIO *rbio) { + if (sslvc->ssl->rbio != NULL) { + BIO_free (sslvc->ssl->rbio); + } sslvc->ssl->rbio = rbio; } + +void +SSL_bio_assert(SSLNetVConnection *sslvc) +{ + ink_assert(sslvc->ssl->rbio == NULL); + ink_assert(sslvc->ssl->wbio == NULL); +} diff --git a/iocore/net/SSLNetVConnection.cc b/iocore/net/SSLNetVConnection.cc index 1c63002..4b1211f 100644 --- a/iocore/net/SSLNetVConnection.cc +++ b/iocore/net/SSLNetVConnection.cc @@ -127,6 +127,8 @@ namespace { // Private // +void SSL_bio_assert(SSLNetVConnection *sslvc); + static SSL * make_ssl_connection(SSL_CTX * ctx, SSLNetVConnection * netvc) { @@ -134,6 +136,7 @@ make_ssl_connection(SSL_CTX * ctx, SSLNetVConnection * netvc if (likely(ssl = SSL_new(ctx))) { netvc->ssl = ssl; + SSL_bio_assert(netvc); // Only set up the bio stuff for the server side if (netvc->getSSLClientConnection()) { > possible slow leak in v5.2.0 > ---------------------------- > > Key: TS-3261 > URL: https://issues.apache.org/jira/browse/TS-3261 > Project: Traffic Server > Issue Type: Bug > Components: Core > Affects Versions: 5.2.0 > Reporter: Sudheer Vinukonda > Assignee: Susan Hinrichs > Priority: Critical > Fix For: 5.3.0 > > > After fixing the iobuffer leak in TS-3257, the iobuffers seem stable on > v5.2.0, but, there still seems to be a slow memory leak. The RES memory from > top shows 15g after running v5.2.0 in prod for more than 3 days, whereas the > corresponding v5.0 host shows 10g after running for more than a week. > Below is the dump of iobuffers between the v5.2.0 and v5.0 host - as > expected, most iobufs are lower than v5.0 host (since, the v5.0 host been > running longer), except the 32k buffer (iobuf[8]). But, the leak doesn't seem > to be explained by the difference in 32k buffers either, as it is not high > enough to explain the 5g difference in total memory. > v5.2.0 host: > {code} > allocated | in-use | type size | free list name > --------------------|--------------------|------------|---------------------------------- > 67108864 | 25165824 | 2097152 | > memory/ioBufAllocator[14] > 2013265920 | 1825570816 | 1048576 | > memory/ioBufAllocator[13] > 620756992 | 549978112 | 524288 | > memory/ioBufAllocator[12] > 780140544 | 593494016 | 262144 | > memory/ioBufAllocator[11] > 742391808 | 574619648 | 131072 | > memory/ioBufAllocator[10] > 901775360 | 735576064 | 65536 | > memory/ioBufAllocator[9] > 1189085184 | 1093304320 | 32768 | > memory/ioBufAllocator[8] > 474480640 | 348733440 | 16384 | > memory/ioBufAllocator[7] > 269221888 | 211320832 | 8192 | > memory/ioBufAllocator[6] > 156762112 | 142999552 | 4096 | > memory/ioBufAllocator[5] > 0 | 0 | 2048 | > memory/ioBufAllocator[4] > 131072 | 0 | 1024 | > memory/ioBufAllocator[3] > 65536 | 0 | 512 | > memory/ioBufAllocator[2] > 65536 | 256 | 256 | > memory/ioBufAllocator[1] > 16384 | 0 | 128 | > memory/ioBufAllocator[0] > {code} > v.5.0.0 host: > {code} > allocated | in-use | type size | free list name > --------------------|--------------------|------------|---------------------------------- > 134217728 | 31457280 | 2097152 | > memory/ioBufAllocator[14] > 2147483648 | 1843396608 | 1048576 | > memory/ioBufAllocator[13] > 788529152 | 608174080 | 524288 | > memory/ioBufAllocator[12] > 897581056 | 680525824 | 262144 | > memory/ioBufAllocator[11] > 796917760 | 660471808 | 131072 | > memory/ioBufAllocator[10] > 985661440 | 818479104 | 65536 | > memory/ioBufAllocator[9] > 873463808 | 677969920 | 32768 | > memory/ioBufAllocator[8] > 544735232 | 404439040 | 16384 | > memory/ioBufAllocator[7] > 310902784 | 237887488 | 8192 | > memory/ioBufAllocator[6] > 160956416 | 115515392 | 4096 | > memory/ioBufAllocator[5] > 0 | 0 | 2048 | > memory/ioBufAllocator[4] > 131072 | 2048 | 1024 | > memory/ioBufAllocator[3] > 65536 | 0 | 512 | > memory/ioBufAllocator[2] > 98304 | 50688 | 256 | > memory/ioBufAllocator[1] > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)