Steve Hay wrote:
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?
Grep the test suite code for cleanup_register. could also check the tracing (but grep is probably easier)
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.
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. 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.
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. 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.
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.
-- __________________________________________________________________ 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]
