[Vm-dev] Memory leak in the SqueakSSL plugin on unix
David T. Lewis
lewis at mail.msen.com
Wed Oct 23 12:29:19 UTC 2013
On Wed, Oct 23, 2013 at 04:21:10AM +0200, Levente Uzonyi wrote:
> On Tue, 22 Oct 2013, David T. Lewis wrote:
> >On Sun, Oct 20, 2013 at 05:50:20AM +0200, Levente Uzonyi wrote:
> >>On Sat, 19 Oct 2013, David T. Lewis wrote:
> >>>Hi Levente,
> >>>I opened a Mantis issue to make sure this does not get overlooked:
> >>Thanks. I've attached the file with the changes.
> >>>Do you now have an updated sqUnixOpenSSL.c that fixes the memory leak
> >>>problem? If so can you please post the file here (or attach it to the
> >>>report)? I understand the changes from your original message but I'm not
> >>>clear if more work needs to be done related to "the BIO_free_all calls
> >>>not needed in general".
> >>>The sqUnixOpenSSL.c file is identical on trunk and oscog, so we can apply
> >>>your fix to both branches.
> >>I made some changes, and it seems like the leakage is gone. I only ran a
> >>short test of a few thousand connections, but I didn't experience any
> >>increase in memory usage with the new code. You can find the modified file
> >>here: http://leves.web.elte.hu/squeak/sqUnixOpenSSL.c
> >>Both the cmake (for the interpreter) and the automake (for Cog) configs
> >>will have to be created/updated to be able to build a functional plugin.
> >Hi Levente,
> >You mention that the cmake configs for interpreter VM may need to be
> >for SqueakSSL, but when I compile the VM on my Linux PC it seems to be
> >I actually do not know how to test the SSL plugin, but it seems to be
> >and all of the primitives are present in the module.
> > lewis at linux-jh8m:~/squeak/build/SqueakSSL> ls -l
> > total 60
> > drwxr-xr-x 3 lewis users 4096 2013-10-19 12:45 CMakeFiles
> > -rw-r--r-- 1 lewis users 1908 2013-10-19 12:45 cmake_install.cmake
> > -rw-rw-rw- 1 lewis users 509 2013-10-19 12:45 CMakeLists.in
> > -rw-rw-rw- 1 lewis users 683 2013-10-19 12:45 CMakeLists.txt
> > -rw-rw-rw- 1 lewis users 41 2013-10-19 12:45 config.cmake
> > -rw-r--r-- 1 lewis users 11126 2013-10-19 12:45 Makefile
> > -rwxr-xr-x 1 lewis users 27740 2013-10-19 20:35 so.SqueakSSL
> > lewis at linux-jh8m:~/squeak/build/SqueakSSL> size so.SqueakSSL
> > text data bss dec hex filename
> > 17236 1024 48 18308 4784 so.SqueakSSL
> > lewis at linux-jh8m:~/squeak/build/SqueakSSL> nm so.SqueakSSL | grep
> > primitive
> > 0000000000001bc0 T primitiveAccept
> > 0000000000001da0 T primitiveConnect
> > 0000000000001f80 T primitiveCreate
> > 0000000000002000 T primitiveDecrypt
> > 00000000000021e0 T primitiveDestroy
> > 0000000000002280 T primitiveEncrypt
> > 0000000000002460 T primitiveGetIntProperty
> > 0000000000002550 T primitiveGetStringProperty
> > 0000000000002730 T primitiveSetIntProperty
> > 0000000000002840 T primitiveSetStringProperty
> >This looks like it should work. Is there an easy way that I can test the
> >plugin and verify that it is working?
> The first thing you can do is to check with ldd if so.SqueakSSL actually
> links to the openssl libraries. If the -lssl and -lcrypto flags are
> omitted during linking, then the plugin will be compiled, but it will not
> be functional (all the primitives will be there, but they will fail),
> because the plugin won't even try to use the openssl libraries.
Thanks. I think that Ian has already added the necessary update for cmake,
because it is building with the -lssl and -lcrypto flags and ldd confirms
that the libraries are being linked.
lewis at linux-jh8m:~/squeak/build/SqueakSSL> ldd so.SqueakSSL
linux-vdso.so.1 => (0x00007fff318de000)
libssl.so.1.0.0 => /lib64/libssl.so.1.0.0 (0x00007f66ee59c000)
libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007f66ee1ec000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f66edfe8000)
libz.so.1 => /lib64/libz.so.1 (0x00007f66eddd2000)
libc.so.6 => /lib64/libc.so.6 (0x00007f66eda71000)
> Other than that, the SqueakSSL-Tests package has some tests (some require
> internet access to google and yahoo).
> If you load SqueakSSL-Core and SqueakSSL-Tests, then 12 tests should pass
> in a Trunk image. Two tests should fail with an error, because Socket >>
> accept returns a Socket instead of SecureSocket. The solution is to change
> the method to
> Socket >> accept
> "Accept a connection from the receiver socket.
> Return a new socket that is connected to the client"
> ^self class acceptFrom: self
> or implement #accept in SecureSocket as
> ^SecureSocket acceptFrom: self
Thanks for the explanations. I am getting errors in the tests, but I think it
is due to the plugin not being 64-bit clean (I am compiling as 64-bit). But
that is a separate problem, and it looks like the plugin should work as expected
on 32-bits. I'll try to compile in 32-bits to confirm when I get some time
to install the 32-bit libraries.
More information about the Vm-dev