perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <steve....@uk.radan.com>
Subject Re: t/perl/ithreads.t revisited
Date Thu, 09 Dec 2004 10:47:02 GMT
Stas Bekman wrote:

>Steve Hay wrote:
>  
>
>>Steve Hay wrote:
>>
>>
>>    
>>
>>>I'll try whittling down the conf even further.
>>>
>>>      
>>>
>>The attached conf & extra startup script is fairly minimal and still 
>>causes this sequence to crash:
>>
>>    perl t/TEST -verbose t/modules/reload.t t/perl/api.t t/perl/ithreads.t
>>
>>But if I comment-out the line:
>>
>>    PerlModule TestPerl::hash_attack
>>
>>then the tests succeed.
>>
>>If I restore that line, but change t/response/TestPerl/hash_attack.pm so 
>>that it only contains:
>>
>>    package TestPerl::hash_attack;
>>    1;
>>
>>then ithreads.t crashes again!
>>
>>Bizarre.  Is this worth pursuing any further?
>>    
>>
>
>I have some ideas. I wonder if those notes from xs/APR/Pool/APR__Pool.h 
>could be relevant to this problem:
>
>/* XXX: this implementation has a problem with perl ithreads. if a
>  * custom pool is allocated, and then a thread is spawned we now have
>  * two copies of the pool object, each living in a different perl
>  * interpreter, both pointing to the same memory address of the apr
>  * pool.
>  *
>  * need to write a CLONE class method could properly clone the
>  * thread's copied object, but it's tricky:
>  * - it needs to call parent_get() on the copied object and allocate a
>  *   new pool from that parent's pool
>  * - it needs to reinstall any registered cleanup callbacks (can we do
>  *   that?) may be we can skip those?
>  */
>
>In your minimum setup try to get rid of most of the parts in:
>
>C:\Temp\mod_perl-2.0\t\conf\modperl_extra.pl
>
>and make sure that no pool cleanup is registered and see if you still get 
>a crash.
>  
>
I'll look into this.  How do I tell if any pool cleanup is registered, 
though?

>Again, you will probably make a much nicer progress using
>http://apache.org/~geoff/bug-reporting-skeleton-mp2.tar.gz
>
Sadly not.  Attached is the .tar.gz that I made, but it passes all tests 
successfully!

As noted before, the minimal configuration that I've come up with myself 
(i.e. not involving the bug reporting skeleton) seems to be sensitive to 
the inclusion or otherwise of seemingly unrelated code / directives.  
The slightest deviation from the conf that I last posted can result in 
the tests suddenly working, hence the bug reporting skeleton is no good 
here since it doesn't give me anything like the control over the 
httpd.conf that I seem to need.

When I run "nmake test" with the attached tarball it generates a huge 
new httpd.conf, full of the crap that I've spent ages slowly whittling 
away from it :(

- Steve


------------------------------------------------
Radan Computational Ltd.

We would like to take this opportunity to wish all our customers, suppliers and colleagues
seasons greetings.  We will not be sending corporate greetings cards this year.  Instead,
we will be making a donation to charity.

The information contained in this message and any files transmitted with it are confidential
and intended for the addressee(s) only.  If you have received this message in error or there
are any problems, please notify the sender immediately.  The unauthorized use, disclosure,
copying or alteration of this message is strictly forbidden.  Note that any views or opinions
presented in this email are solely those of the author and do not necessarily represent those
of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached
files for viruses: Radan Computational will accept no liability for any damage caused by any
virus transmitted by this email.
Mime
View raw message