--- On Thu, 24/1/13, Sven Van Caekenberghe <sven@stfx.eu> wrote:
From: Sven Van Caekenberghe <sven@stfx.eu> Subject: Re: [Pharo-users] Memory Leak with Zodiac? To: "A friendly place where any question about pharo is welcome" <pharo-users@lists.gforge.inria.fr> Date: Thursday, 24 January, 2013, 10:41 Hi Chris,
On 24 Jan 2013, at 11:02, CHRIS BAILEY <cpmbailey@btinternet.com> wrote:
I'm having a little trouble with a possible memory leak with Zodiac. I'm running Pharo 1.4 Summer on Centos 6.3/Fedora 18 for deploy/dev. The plugin is using libssl.so.0.9.8, and I also seem to have another version kicking about which uses libssl.so.6 and am not really sure where I got that from. It may be an older one from the http://code.google.com/p/squeakssl/ site. Both have the same effect, i.e. when running 100 timesRepeat: [ ZnClient new url: 'https://www.google.com'; get ] VIRT and RES memory both go up about 70mb, but just using http doesn't accumulate any. I tried it in Pharo 2.0 which was the same, but the new NBCog doesn't include the libSqueaKSSL.so so I was only copying it over.
Has anyone used it successfully in the same environment? I'll try it on Ubuntu when I get a chance.
Thanks Chris
Thanks for testing this ;-)
Note that although ZnClient is most often used to do just one request, it was also designed to be reused to do multiple request to the same host:port. Even when not taking care of resource cleanup, for casual use #close to the socket will eventually be sent where necessary due to finalization. Helping a bit makes for better performance.
Either one of the following would be better:
100 timesRepeat: [ ZnClient new beOneShot; get: 'https://www.google.com' ].
100 timesRepeat: [ ZnClient new get: 'https://www.google.com'; close ].
| client | client := ZnClient new. 100 timesRepeat: [ client get: 'https://www.google.com' ]. client close.
Now, Zodiac TLS/SSL Streams are more resource intensive: they create ZdcPluginSSLSession instances which represent native native data structures from the OS's SSL libraries. These are only cleaned up when #destroy is sent, which is one by ZdcSecureSocketStream>>#close. I didn't write any explicit code to do this by finalization, so that probably does not happen. Maybe we should experiment with adding a #finalize to ZdcPluginSSLSession as an equivalent to #destroy.
It would be cool if you could test again. Hopefully memory consumption improves.
Hi Sven, thanks for the quick reply. Sorry, I didn't consider that when I reproduced it with the simplest example I could think of! I'm actually using it in the context of a single ZnClient being held open for an entire Seaside session which talks to an external web service. I therefore only send a close when the session ends. What solution would you recommend, as it is quite easy currently to run the image out of memory before the session gets unregistered. Thanks Chris