perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philippe M. Chiasson" <go...@ectoplasm.org>
Subject Re: [mp2] pools that go out of scope aren't a problem anymore?
Date Mon, 06 Dec 2004 05:04:26 GMT


Stas Bekman wrote:
> Joe Schaefer wrote:
> 
>> "Philippe M. Chiasson" <gozer@ectoplasm.org> writes:
>>
>>
>>> my $pool;
>>> sub handler {
>>>  my $r = shift;
>>>  $pool ||= $r->pool; #XXX: Yes, bad bad bad, but still...
>>>  APR::Table::make($pool, 10); #bam!
>>> }
>>>
>>> The problem in this case is that apache destroyed the request pool at
>>> the end of the first request. And we now have a valid $pool that now
>>> points to a freed pool. It's an incorrect usage of the API, I know,
>>> but the resulting segv isn't nice... 
>>
>>
>>
>> This is a problem with persistence, not "ownership", and affects the
>> entirety of mp2's object system.  In other words, there's no reason to 
>> single out pools in your example, the bug could just as easily been
>>
>> my $r;
>>
>>    sub handler {
>>        $r ||= shift;
>>        my $pool = $r->pool; #bam!
>>    }
>>
>> "Fixing" this problem is certainly a challenge, but IMO not
>> worth worrying about for 2.0.
> 
> Agreed.

I agree as well.

> That's said this issue is not critical for RC1, since they user API 
> won't change, we can work on it in parallel, but certainly will finish 
> it before the gold release.

I agree. I think it's important to make sure that whatever perl code our users
end up writing, that they are not able to segfault the server. Preventing/detecting
this particular kind of problem will be tricky though.
 
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5 
http://gozer.ectoplasm.org/     F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5

Mime
View raw message