[
https://issues.apache.org/jira/browse/TS-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14259543#comment-14259543
]
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)
