perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [mp2] pools that go out of scope aren't a problem anymore?
Date Sat, 18 Dec 2004 01:06:08 GMT
Stas Bekman wrote:
> I've rebuit with --enable-pool-debug CPPFLAGS="-DAPR_BUCKET_DEBUG", but 
> also apr1/httpd2.1
>>>   % ~/perl/5.8.x/bin/perl -MApache2 -MAPR::Pool -MAPR::Table -wle '
>>>   $t= APR::Table::make(APR::Pool->new, 10);   $t->set($_=>$_), print

>>> "Set $_" for 1..20'
>>>   Segmentation fault
> Now I get the segfault

I get it also with apr-0.9/httpd-2.0.

I'm back to work on this temp pool object issue. I've found what I think 
is another problem.

     APR::Pool p

So if we link pool to alloc, everything is cool, but when this alloc is 
used to create something and then goes out of scope as in:

      my $ba = APR::Bucket::alloc_create(APR::Pool->new);
      $b = APR::Bucket::eos_create($ba);

now $b guts are wiped, since $ba and the temp pool are gone. Am I right?

In which case it's not enough to make pool's destroy on the other objects 
that use it, but it goes further down the chain, in this example the 
bucket needs to link the allocator so that doesn't get nuked before the 
bucket is done with its scope?

There are probably other chain dependency issues.

I think there is one more problem with preventing from the temp object 
pools being destroyed this is related to the problem previously discovered 
with modperl_bucket.c:

     /* PADTMP SVs belong to perl and can't be stored away, since perl
      * is going to reuse them, so we have no choice but to copy the
      * data away, before storing sv */
     if (SvPADTMP(sv)) {
         STRLEN len;
         char *pv = SvPV(sv, len);
         svbucket->sv = newSVpvn(pv, len);

so for example I think this code:

   sub make_table {
      return APR::Table::make(APR::Pool->new, 10);
   push @tables, make_table() for 1..2;
   for my $table (@tables) {
       $table->set($_ => $_) for 1..20;
   for my $table (@tables) {
       print $table->get($_) for 1..20;

has a problem, since the temp pool in the sub is PADTMP SV, which means 
that perl will want to reuse the same SV everytime the sub is entered. so 
what happens to the pool which can't be destroyed, but perl will overwrite 
it with a new data. I didn't actually run the test yet.

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

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

View raw message