perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: t/perl/ithreads.t revisited
Date Wed, 08 Dec 2004 22:46:51 GMT
Steve Hay wrote:
> Steve Hay wrote:
>>I'll try whittling down the conf even further.
> The attached conf & extra startup script is fairly minimal and still 
> causes this sequence to crash:
>     perl t/TEST -verbose t/modules/reload.t t/perl/api.t t/perl/ithreads.t
> But if I comment-out the line:
>     PerlModule TestPerl::hash_attack
> then the tests succeed.
> If I restore that line, but change t/response/TestPerl/ so 
> that it only contains:
>     package TestPerl::hash_attack;
>     1;
> then ithreads.t crashes again!
> Bizarre.  Is this worth pursuing any further?

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:


and make sure that no pool cleanup is registered and see if you still get 
a crash.

Again, you will probably make a much nicer progress using

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message