perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [mp2] pool object dependant methods insanity
Date Fri, 24 Dec 2004 19:00:44 GMT
Joe Schaefer wrote:
> Stas Bekman <> writes:
>>Joe Schaefer wrote:
>>>        $bucket->setaside($pool) means
>>>the apr_bucket_t attached to this APR::Bucket object needs to
>>>survive as long as the underlying apr_pool_t. However, if
>>>that apr_pool_t is owned by some APR::Pool object, that object
>>>should [*] survive at least as long as the APR::Bucket object does.
> [...]
>>So what do we hang the pool on? $bucket?
> +1.
>>That doesn't sound right, since the perl object may go away (thus
>>destroying the pool if noone else references it), but the underlying
>>bucket can't see that. so it's probably not enough, no?
> It is enough, if you're sticking to the text above.
> The pool is going to die at some point; the application 
> (not mp2) has a bug if the bucket is used beyond that point.

Right. Thanks for that idea, Joe.

BTW, I've found a nice way to write tests for this dependency issue (not 
only this particular method). Instead of trying to hope for a random 
segfault, I simply create a new pool and use it to create some huge apr 
table or something and then verify that the object created with the 
previous temp pool is still valid, if the pool was freed too early, it'll 
be corrupred, 100% certainly giving either wrong data or segfaults, 
regardless whether --enable-pool-debug is in effect.

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

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

View raw message