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.
