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:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
