Re: m2crypto beta release

Heikki Toivonen wrote:
> Matt Rodriguez wrote:
>   
>> 1. test_ssl.py is not working for me. The problem is the unittests for
>> the SSLClientTestCase. All of these tests fail with a Connection refused
>> error. I haven't looked into
>> this any deeper than this, because I'm just doing some preliminary
>> checks right now. The rest of the unittests work flawlessly for me.
>>     
>
> The SSL tests are somewhat problematic. They try to launch the openssl
> command line test server against which the client testcases run. So if
> you don't have OpenSSL in your path, or have some firewall rules you
> might get failed results.
>
> The good thing about using that external program is that it does more
> "real" testing than running against an in-memory test server. But that
> would be a nice alternative to have.
>
>   
I think using the openssl should be ok, but maybe a few more checks 
should be made before the
tests are run. For example we could check if openssl is in the path, and 
then maybe a simple connection
test should be run first. If that fails, the test exits with an error 
explaining the rest of the tests will fail.

>> 2. There still are a bunch of compiler warnings. These just need to go
>> away before the final release. I've noticed that SWIG-1.3.24 generates
>> code that
>> produces compiler warnings, these warnings go away in SWIG 1.3.25. I
>> know I suggested that we should make 1.3.24 a requirement, but I would
>> say that we should
>> probably just require 1.3.25. We should have a simple check in the
>> setup.py script to ensure that we are using an appropriate version of
>> SWIG. Below you'll find the
>> compiler warnings that we need to get rid of.
>>     
>
> I don't think the requirements can be changed this late.
>
> It's also problematic that you get different warnings based on different
> SWIG versions, compiler versions and OpenSSL versions. I've fixed most
> warnings, but it was starting to look like spending more effort on these
> would become harder and harder without actually buying that much.
>
> Some examples of frustrating warnings include a bunch of functions that
> SWIG generates but which are not used.
>
>   
Agreed.

> I can work on integrating patches for the warnings, but I doubt I would
> be doing much work myself on these for 0.16.
>
>   
I think fixing all of the warnings in the SWIG generated code across all 
accepted versions of SWIG will be
difficult with the current accepted versions of SWIG. I can accept that 
it's a little late to update the requirements
for this project.  But I think that fixing the other compiler warnings 
should be fairly simple, and I will submit a patch
that does that.
>> 3. I ran valgrind on all of the unittest files except, test_ssl,
>> test_ssl_win, and alltests, I found some leaks in test_x509, but I
>> suspect that it is the issue is how the tests are
>> written, and not any underlying problem in the toolkit. Below you'll
>> find the valgrind output
>>     
>
> Could you explain how to run Valgrind on the tests, I am afraid I've
> never used Valgrind? (Well, I've used kcachegrind to view python hotshot
> profiles, which isn't helping much.)
>
> I'll also see if I can figure out how to read the results you posted.
>
> Thanks,
>
>   
Valgrind is a great tool and pretty simple to use. I think you can only 
use it on Linux, there is a powerpc port out there, but I
don't know what the status on that is.

 %valgrind --leak-check=yes program_name

That'll give you a summary report at the end.

Sometimes I use --error-limit=no when I'm working with debugging the 
openssl libraries, because
there are a little things in openssl that valgrind complains about.


Matt