[Vm-dev] Memory leak in the SqueakSSL plugin on unix

[Levente Uzonyi]

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:
>>>
>>> http://bugs.squeak.org/view.php?id=7793
>>
>> 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
>>> Mantis
>>> 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


Levente


>
> Thanks,
> Dave
>
>