Skip Menu |
 

This queue is for tickets about the IO-Socket-SSL CPAN distribution.

Report information
The Basics
Id: 123520
Status: resolved
Priority: 0/
Queue: IO-Socket-SSL

People
Owner: Nobody in particular
Requestors: NATARAJ [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 2.052
Fixed in: (no value)



Subject: Yet another memory leak
MIME-Version: 1.0
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
Message-ID: <rt-4.0.18-15061-1509894195-1238.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 1848
Download (untitled) / with headers
text/plain 1.8k
IO::Socket::SSL is still leaking the memory even if one take care about #120643 by setting SSL_ocsp_mode => SSL_OCSP_NO_STAPLE If I run the script that creates and closes SSL socket and watches for memory used by it, it will show constant growth of memory used The script I used is use strict; use Memory::Usage; use IO::Socket::SSL; my $mu = Memory::Usage->new(); foreach my $i(1..100) { print $i,"\n"; $mu->record($i); foreach (1..100) { my $cl = IO::Socket::SSL->new(PeerAddr=>'en.wikipedia.org:443' ,SSL_ocsp_mode => SSL_OCSP_NO_STAPLE); $cl->close; sleep 1; # Be polite, do not DDOS wikipedia } } $mu->dump(); The output it gives is like time vsz ( diff) rss ( diff) shared ( diff) code ( diff) data ( diff) 0 16064 ( 16064) 11320 ( 11320) 6188 ( 6188) 2280 ( 2280) 5400 ( 5400) 1 118 17972 ( 1908) 14296 ( 2976) 7356 ( 1168) 2280 ( 0) 7172 ( 1772) 2 237 18236 ( 264) 14620 ( 324) 7420 ( 64) 2280 ( 0) 7436 ( 264) 3 355 18632 ( 396) 14884 ( 264) 7420 ( 0) 2280 ( 0) 7832 ( 396) 4 473 18896 ( 264) 15148 ( 264) 7420 ( 0) 2280 ( 0) 8096 ( 264) 5 591 19160 ( 264) 15412 ( 264) 7420 ( 0) 2280 ( 0) 8360 ( 264) 6 709 19424 ( 264) 15940 ( 528) 7420 ( 0) 2280 ( 0) 8624 ( 264) 7 827 19820 ( 396) 16204 ( 264) 7420 ( 0) 2280 ( 0) 9020 ( 396) 8 945 20084 ( 264) 16468 ( 264) 7420 ( 0) 2280 ( 0) 9284 ( 264) 9 1063 20348 ( 264) 16732 ( 264) 7420 ( 0) 2280 ( 0) 9548 ( 264) 10 You see, data and vsz constantly growing... The rate is less than in #120643 but it is still here... I tied it on current Debian Sid with perl 5.26.1, IO::Socket::SSL 2.052 and Net::SSLeay 1.80
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-15061-1509894195-1238.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-15061-1509894195-1238.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-14257-1516202324-1696.123520-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 300
Download (untitled) / with headers
text/plain 300b
Show quoted text
> I tied it on current Debian Sid with perl 5.26.1, IO::Socket::SSL > 2.052 and Net::SSLeay 1.80
I can see no such leaks with Net::SSLeay 1.84 which has incorporated my memory leak fixes for OCSP. Therefore I close this bug. If you still see these problems please reopen the bug with more details.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.