apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sander Striker <stri...@apache.org>
Subject Re: apr pool arch shortcoming: lack of pool validation API
Date Sun, 25 Jan 2004 10:29:19 GMT
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).

Sander

Mime
View raw message