Mailing-List: contact dev-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <41B912E4.6040107@stason.org>
Date: Thu, 09 Dec 2004 22:07:16 -0500
From: Stas Bekman <stas@stason.org>
Organization: Hope, Humanized
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
MIME-Version: 1.0
To: Steve Hay <steve.hay@uk.radan.com>
Cc: "Philippe M. Chiasson" <gozer@ectoplasm.org>,
	mod_perl Dev <dev@perl.apache.org>,
	Randy Kobes <randy@theoryx5.uwinnipeg.ca>
Subject: Re: t/perl/ithreads.t revisited
References: <41A63198.6090503@stason.org> <41A75AB8.7040304@uk.radan.com>
 <41A7726D.2060302@uk.radan.com> <41A7738E.3030801@stason.org>
 <41AEBFB6.3060300@ectoplasm.org> <41B48CA3.7020509@uk.radan.com>
 <41B49E18.6000308@uk.radan.com> <41B7845B.2090405@stason.org>
 <41B82D26.2040802@uk.radan.com>
In-Reply-To: <41B82D26.2040802@uk.radan.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org