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.
I suppose so.
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.
It gives you exactly the same level of control as the modperl test suite. No more and no less.
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.)
Well, actually it's not exactly true. I think only to those packages that define DESTROY function (the CLONE is needed so that DESTROY won't try to free the same C struct more than once). And APR::Pool is one of those candidates needing CLONE. It'll become even more crucial when we create the dependencies on pool objects in methods that take the pool object.
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.
It doesn't.
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?
It's a feature. *.t is autogenerated if t/response/*/*.pm is found. So if you want to create some module which is *not* a response handler, put it in t/lib or lib instead.
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.
It's still a manual error-work prone to do. And it will be lost every time 'make test' is run. Not fun.
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!
But it keeps your stuff in your file.
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 :(
See above.
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.
Any chance you can make the failing tarball, which already includes all the above?
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?
I think the only difference is that you don't add this path to @INC:
use lib 'C:/Temp/bug-reporting-skeleton-mp2/t';
Otherwise PerlSwitches add path to @INC at the interpreter startup, use lib adds those at run time. And also use libs loads a few extra modules.
When you talk about crashes it's quite possible that asking for more or less memory will affect the crash, since may be that exact extra allocation has caused an access violation. And if that's the cause, it's going to be very hard to reproduce it on a different OS where the memory allocation and access processes are very different.
In any case I want us to have a tarball, which fails for you and we can for example give it to Randy or Gisle and see if crashes for him. And then if we try various fixes we can again test whether it still fails. Note that the ever evolving mp2 test suite may just stop crashing for you when new tests are added. That's why I want to freeze that moment.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
