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 Fri, 10 Dec 2004 14:50:34 GMT
Stas Bekman wrote:

>>>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?
>>    
>>
>
>Grep the test suite code for cleanup_register. could also check the 
>tracing (but grep is probably easier)
>  
>
Grepping shows that only these files mention "cleanup_register":

conf/post_config_startup.pl
hooks/TestHooks/cleanup2.pm
lib/TestAPIlib/pool.pm
response/TestAPI/request_util.pm
response/TestAPI/server_util.pm
response/TestAPR/pool.pm

My minimal conf doesn't mention any of those, so I guess we're OK there.


>  
>
>>>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!
>>    
>>
>
>Excellent :) So you need to find what's the difference between the two.
>  
>
A lot!...

>  
>
>>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.
>>    
>>
>
>The bug reporting skeleton is just as good as the mp2 test suite. The only 
>difference is that with mp2 test suite you start with a lot and then you 
>cut down. and withe the skeleton you start with nothing and add things up. 
>Of course if you prefer to work with the test suite that is perfectly fine.
>
>Those seemingly unrelated code chunks/directives can in fact be very 
>related to crash. 
>
Absolutely.  That's why I need to have a level of control over them 
which the skeleton doesn't afford me.

>Most likely we need to add CLONE function to all modules 
>that return objects. I guess that's a very possible reason for the 
>ithreads test crash. Notice that ithreads2 doesn't crash, since it runs 
>against a different perl pool with very little code loaded.
>  
>
That gives me a lovely warm feeling.  (Down the inside of my leg.)

>  
>
>>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 :(
>>    
>>
>
>What do you mean? I can't see any crap in it. What things you didn't want 
>to show up (do you mean the prefork and other unrelated config chunks?) 
>just disregard those, since they certainly have nothing to do with the 
>problem. 
>
Well, the output of the skeleton thing is well over 3 times the size of 
my minimal setup, which I just felt was a step backwards.  Maybe the 
extra stuff doesn't matter, as you say.

What *is* a pain, though, is that I noted previously that if I delete 
the "PerlModule TestPerl::hash_attack" line from my minimal conf then it 
suddenly works (even though has_attack.pm just contains "1;").  My 
original skeleton didn't include hash_attack, so it occurred to me that 
that maybe why it worked.  But when I dropped a suitable hash_attack.pm 
in place, I now find that the generated .conf file contains:

<Location /TestPerl__hash_attack>
    SetHandler modperl
    PerlResponseHandler TestPerl::hash_attack
</Location>

and it tries to run a t/perl/hash_attack.t test, even though not such 
file exists!  This causes the server to crash:

t\perl\hash_attack....request has failed (the response code was: 500)
see t/logs/error_log for more details
t\perl\hash_attack....dubious
        Test returned status 9 (wstat 2304, 0x900)

so it never even gets to the ithreads test!

Surely which tests get run should depend on which tests exist (*.t 
files), rather than which t/response/*.pm files exist?

>The good thing is that we can pass the tarball around w/o having 
>a problem with hardcoded path, which your originally submitted config file 
>had, which is certainly not runnable on my machine without painful manual 
>tweaks.
>  
>
There's only 10 Windows paths in it.  I don't see that anything else 
needs changing.

>If you want to keep your config file in this tarball to a minimum create:
>
>   t/conf/steve.conf.in
>
>or
>
>   t/conf/steve.last.conf.in
>
>depending on when do you do you want it to be included. and put all the 
>stuff there. It will be automatically included on t/TEST -conf.
>
That just seems to include my stuff *as well as* all the stuff that it's 
already generated itself.  So now I have an even larger conf!

I am singularly unable to persuade the test skeleton to generate a 
minimal (or even slightly larger) conf file with the "PerlModule 
TestPerl::hash_attack" in the appropriate place without it also trying 
to run some tests that don't exist :(

Attached is a new test skeleton.  I am able to reproduce the failure 
using the skeleton in the following way (the usual "perl Makefile.PL / 
make / make test" sequence won't work because of the hash_attack problem 
described above):

1. Extract tarball

2. Run "perl Makefile.PL -apxs C:\apache2\bin\apxs.bat" [or wherever 
your apxs is] to generate a t/TEST

3. Run "perl t/TEST t/modules/reload.t t/perl/api.t t/perl/ithreads.t" 
to explicitly run the tests that actually exist ;)  This succeeds at 
this stage -- all tests OK.

4. Edit t/conf/httpd.conf as follows:

4a.  Change the lines that look something like this:

<IfModule mod_perl.c>
    PerlRequire C:\Temp\bug-reporting-skeleton-mp2\t\conf\modperl_startup.pl
</IfModule>

to something like this instead:

PerlSwitches -IC:\Temp\bug-reporting-skeleton-mp2\t\response
PerlSwitches -IC:\Temp\bug-reporting-skeleton-mp2\t\lib
PerlModule Apache2

4b.  Insert the line:

PerlModule TestPerl::hash_attack

just before the lines:

<Location /TestPerl__hash_attack>
    SetHandler modperl
    PerlResponseHandler TestPerl::hash_attack
</Location>

5. Run "perl t/TEST t/modules/reload.t t/perl/api.t t/perl/ithreads.t" 
again.  This time, the ithreads.t test crashes the server.

As before, the crash doesn't happen without that hash_attack line.

I don't know why replacing modperl_startup.pl with PerlSwitches is 
necessary to reproduce the crash here.  (Clearly it wasn't necessary in 
the main mp2 test suite, or I'd never have found the crash to start 
with!)  My modperl_startup.pl contains just:

BEGIN {
    use lib 'C:/Temp/bug-reporting-skeleton-mp2/t';
    for my $file (qw(modperl_inc.pl modperl_extra.pl)) {
        eval { require "conf/$file" } or
            die if grep { -e "$_/conf/$file" } @INC;
    }
}

There is no modperl_extra.pl, and modperl_inc.pl only contains:

use lib 'C:\Temp\bug-reporting-skeleton-mp2\t\response';
use lib 'C:\Temp\bug-reporting-skeleton-mp2\t\lib';
use Apache2;

so I would have thought the change described above achieves nothing.  
What's the difference?

- 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