On 04/11/2011 05:13 PM, Michal Trojnara wrote:
Sven Ulland wrote:
The Massif log indicates that most of the memory is allocated through client.c:init_ssl(), by libssl and zlib. I haven't looked too much at the code yet, but could this be related to the high rate of connection resets/timeouts, combined with connection/session reuse?
I guess you're right. A trivial workaround would be to build OpenSSL without zlib. 8-)
BTW: What is your version of OpenSSL?
The initial report was based on OpenSSL 0.9.8g. I then compiled 0.9.8r without zlib, and it ran well and without any obvious leaks. A massif output of that run is attached: It shows memory use of 314MB while idle (after having served a lot of connections). Is it so that the number of ssl/connections allocated by stunnel is always the maximum observed throughout the entire runtime, i.e. it never frees up idle connections? That's not really a problem, I'm just curious.
What I should have done earlier is to check the OpenSSL change log.
""" Changes between 0.9.8n and 1.0.0 [29 Mar 2010] [...] Fix compression algorithm handling: if resuming a session use the compression algorithm of the resumed session instead of determining it from client hello again. Don't allow server to change algorithm. """
I'm not sure if this was backported to 0.9.8r, but there's also this:
""" Changes between 0.9.8l and 0.9.8m [25 Feb 2010] [...] Modify compression code so it frees up structures without using the ex_data callbacks. This works around a problem where some applications call CRYPTO_cleanup_all_ex_data() before application exit (e.g. when restarting) then use compression (e.g. SSL with compression) later. This results in significant per-connection memory leaks and has caused some security issues including CVE-2008-1678 and CVE-2009-4355. """
I recompiled 0.9.8r with zlib enabled again, but it's not clear to me if zlib was actually used in the following run or not. At least there were no zlib or libz strings in the massif output.
I'll assume it's the OpenSSL issues that were at fault, and then continue to run with the new lib version. If there is any new development in the upcoming days, I'll send a follow-up.
sven