[Vm-dev] Memory leak in the SqueakSSL plugin on unix
leves at elte.hu
Wed Oct 23 02:21:10 UTC 2013
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 are
>>> 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 updated
> for SqueakSSL, but when I compile the VM on my Linux PC it seems to be fine.
> I actually do not know how to test the SSL plugin, but it seems to be complete
> 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.
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
More information about the Vm-dev