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
