On Thu, 2010-01-07 at 11:00 -0800, Neil Conway wrote:
> Well, the suggested fix of using a sibling pool to the hash table's
> pool would work, I think -- I'd be happy to prepare patches to
> implement that.
What would you hang the destruction of the array_pool against? The
parent pool? If so, we may have a different memory leak on our hands
(i.e. hash's pool gets whacked, but array_pool persists until the parent
goes away, which could be a long way away).
Hanging it off the hash's pool probably won't work, because depending on
the order of cleanups, this may not run last. So, again, we may end up
with some pool cleanups referring to things that have been deallocated.
Given the code of apr_hash.c, the only place array_pool gets used is
here:
-----------
static apr_hash_entry_t **alloc_array(apr_hash_t *ht, unsigned int max)
{
return apr_pcalloc(ht->array_pool, sizeof(*ht->array) * (max + 1));
}
-----------
Why can't we just use malloc() for this and hang a cleanup off the pool?
It would use less memory anyway than having another pool for this.
Just tossing ideas around...
--
Bojan
