[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Hashtable data freed before pool cleanup

From: Bojan Smojver <bojan_at_rexursive.com>
Date: Fri, 08 Jan 2010 11:15:58 +1100

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
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...

Received on 2010-01-08 03:43:57 CET

This is an archived mail posted to the Subversion Dev mailing list.