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

[Florian Ragwitz]

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

-- 
BOFH excuse #395:
Redundant ACLs. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/net-ssleay-devel/attachments/20060727/68eb4b67/attachment.pgp