apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: apr pool arch shortcoming: lack of pool validation API
Date Sun, 25 Jan 2004 20:34:37 GMT
Sander Striker wrote:
> On Sun, 2004-01-25 at 01:57, Stas Bekman wrote:
> 
>>Recently I've learned about an important feature lacking in apr pool 
>>architecture - it's the ability to verify that the pool is still the same pool 
>>and wasn't destroyed or replaced by another pool.
>>
>>If I create a new pool and stash a pointer to it in 2 variables, it's quite 
>>possible that one variable will call apr_pool_destroy, the other won't know 
>>that the pool has been destroyed. As long as a new pool wasn't allocated, the 
>>other accessor will still be able to use the ghost pool, as if it was there 
>>for real. The moment a new pool will get allocated at the same memory address, 
>>the ghost accessor will wreck havoc operating on the pool that doesn't belong 
>>to it.
>>
>>I think what's needed is to store a unique signature every time a new pool is 
>>created somewhere in the pool and have the API to get and verify that 
>>signature. If this functionality was in place, I could stash that signature 
>>along with the apr_pool_t pointer in my variables and before doing something I 
>>could verify whether I'm still talking to the correct pool.
>>
>>The situation when you have a ghost pointer is very real. Since the parent 
>>pool destroys all its child pools, the variables referencing these child pools 
>>may not know that the parent pool has been destroyed and still try to use the 
>>ghost pools.
>>
>>Thanks.
> 
> 
> This why there is a pool debugging mode.  In production no checks are
> made.  If you run in debug mode, with electric fence or valgrind, you'll
> flush out the type of bugs you mention easily (and a lot more).

I know about the debug mode. But I don't think this is suitable to all. We 
provide a perl API to apr_pool_*. Many users of this API aren't sophisticated 
enough to compile things (they usually use precompiled rpm provided by their 
distro), not talking about using EF or valgrind. These users may write code, 
where a parent pool will be nuked and their code will still try to access 
child pools that are no longer there. As mentioned above this may or may not 
work for them at different times. Therefore I was thinking that we could 
provide an optional or mandatory instrumentation to verify the pool's validity 
before it can be used.

At the moment I've rewritten our APR glue implementation using some perl 
magic, so that it knows to invalidate any objects pointing to a pool, if the 
latter is getting destroyed directly or indirectly (via parent destroy), so I 
think our users are safe. But others may still find the validation API in a 
non-debug mode to be handy or even crucial. Since I have the workaround for 
this issue, it's OK if it's not added/exposed at the moment, but this is 
something that you may want to add in the future.

When I was thinking about it, I came to a conclusion that I could implement 
the signature validation mechanism by myself, by simply storing a unique 
string via apr_pool_user_data_set in the pool, and in the object. And compare 
the two before accessing the pool. So apr_pool could save me the trouble of 
creating this signature and giving me a wrapper to create/read it. I think 
that's all is needed. But may be there are more efficient ways to accomplish 
the validation that I haven't thought about.

__________________________________________________________________
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


Mime
View raw message