[Net-ssleay-devel] Testers for svn trunk, please.

[Mike McCauley]

Hello Florian,

Found a fix for this problem on Windows by using OPENSSL_free() instead of 
free() to free the memory allocated by openssl in X509_NAME_oneline.

During the process I have also fixed a number of cases in SSLeay.xs where 
malloc/free was used instead of New/Safefree

I have committed these changes to svn

There is one malloc() left in ssleay_ctx_passwd_cb_new, but there does not 
seem to be a matching free(). Is that your intention?

There are still test failures in the test suite on Windows, but at least it 
doesnt crash any more. It now hangs in 08_pipe.t

I have also updated and committed  t/local/00_ptr_cast.t so it works on 
Windows.

Now working on the errors in 07_sslecho.t  and the hang in 08_pipe.t

Cheers.


On Thursday 27 July 2006 23:01, Florian Ragwitz wrote:
> On Thu, Jul 27, 2006 at 10:10:33PM +1000, Mike McCauley wrote:
> > Hi Florian,
> >
> > On Wednesday 26 July 2006 22:30, Florian Ragwitz wrote:
> > > On Wed, Jul 26, 2006 at 10:00:11AM +1000, Mike McCauley wrote:
> > > > 3. The link phase of the ssleay.dll fails, because the necessary
> > > > switches set by  ssleay_get_build_opts (lib_paths and lib_links) dont
> > > > end up on the link command line. The resulting link command line is:
> >
> > This problem is now fixed: it required a change in ssleay_get_build_opts,
> > changing
> >         push @{ $opts->{lib_paths} }, "-L$prefix/lib/VC";
> > to
> >         push @{ $opts->{lib_paths} }, "$prefix/lib/VC";
> >
> > I have committed this change to svn.
>
> Great, thanks!
>
> > So now it compiles and links on Windows, but a number of tests fail, and
> > there is a crash:
> >
> > t/local/07_sslecho...............NOK 12
> > #   Failed test 'accept'
> > #   in t/local/07_sslecho.t at line 61.
> > t/local/07_sslecho...............NOK 14
> > #   Failed test 'ssl_read_all'
> > #   in t/local/07_sslecho.t at line 66.
> > #          got: ''
> > #     expected: 'ssleay-test'
> > t/local/07_sslecho...............NOK 15
> > #   Failed test 'ssl_write_all'
> > Use of uninitialized value in string eq at t/local/07_sslecho.t line 110.
> > #   in t/local/07_sslecho.t at line 67.
> > Free to wrong pool 212c88 not 30c0121 at t/local/07_sslecho.t line 220.
> >
> > The debugger shows the crash occurs in ssleay_verify_callback_invoke()
> > inside the call to
> > 	count = call_sv(*callback, G_SCALAR);
> >
> >
> > If I remove all the calls to Net::SSLeay::X509_NAME_oneline from
> > t/local/07_sslecho.t it doesnt crash.
> > If I comment out the free(buf); in X509_NAME_oneline it doesnt crash.
> > But.... X509_NAME_oneline allocs a buffer and what else can you do but
> > free() it? Why does the free crash?
> >
> > The few comments I see about "Free to wrong pool"  indicate that this
> > type of crash is generally a symptom of a memory/thread problem
> > elsewhere. I note that  t/local/07_sslecho.t uses fork() which on Windows
> > uses threads to implement.
>
> I guess it's about the static HVs used to associate the various
> callbacks with the SSL and SSL_CTX pointers. I doubt those are
> thread-safe on the C level. I'd suggest to introduce a locking in the
> functions modifying those HVs. At the moment I don't know how to
> implement that in a cross-platform way. Probably perl already offers
> that kind of functionality, but I don't have the time to check that
> right now, sorry.
>
> I don't really know what's going wrong at the moment in line 110. It
> seems that the glue for SSL_read doesn't return anything. It's probably
> related to the same problem as this function also allocs some memory
> (32768 bytes as the default) and free()s it afterwards.
>
>
> Also, we really need some threaded tests!
>
>
> I'll be able to take a look at the problem next monday.
>
>
>
> Regards,
> Flo

-- 
Mike McCauley                               mikem at open.com.au
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc.