Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 5 Sep 2003 00:32:57 -0400 (EDT)
From: Cliff Woolley <jwoolley@virginia.edu>
To: Chris Fallin <chris@cfallin.org>
cc: dev@apr.apache.org
Subject: Re: Problem avoiding memory leak with thread creation
In-Reply-To: <3F5810A3.9080208@cfallin.org>
Message-ID: <Pine.GSO.4.53.0309050030050.19986@cobra.cs.Virginia.EDU>
References: <3F5810A3.9080208@cfallin.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 4 Sep 2003, Chris Fallin wrote:

> In order to prevent leaks each thread gets its own subpool, which it
> frees on exit. However, I see in apr_thread_create (at
> threadproc/unix/thread.c:160) that a subpool is allocated from the pool
> passed to the function. This pool is the one that is destroyed in
> apr_thread_exit at line 192. Thus, the pool passed in to
> apr_thread_create is never freed unless done manually after
> apr_thread_exit destroys the child pool, which is hard because it exits
> the thread.

As for whether what you described is a bug or not, I'm not sure, but you
might be able to get around it one way or the other by calling
apr_allocator_create() yourself, then apr_pool_create_ex() -- that way
your subpool has its own block of memory that you can destroy after the
thread is done, rather than having it go back into the parent pool's
allocator.  (apr_allocator_max_free_set() might also be useful.)

Hope this helps.  No doubt one of the pool wizards will jump in with other
suggestions...

--Cliff