Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <48E4D9DE.3030503@apache.org>
Date: Thu, 02 Oct 2008 16:25:34 +0200
From: Mladen Turk <mturk@apache.org>
User-Agent: Thunderbird 2.0.0.14 (X11/20080515)
MIME-Version: 1.0
To: Ben Collins-Sussman <sussman@red-bean.com>
CC: Subversion Developers <dev@subversion.tigris.org>,
 dev@apr.apache.org
Subject: Re: apr pools & memory leaks
References: <53c059c90810011111v37c36635y7279870f9bc852a0@mail.gmail.com>
	 <48E47BE1.8060903@apache.org>
 <53c059c90810020647t71810c63nc0682c2f5adaba19@mail.gmail.com>
In-Reply-To: <53c059c90810020647t71810c63nc0682c2f5adaba19@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ben Collins-Sussman wrote:
> On Thu, Oct 2, 2008 at 2:44 AM, Mladen Turk <mturk@apache.org> wrote:
>> Ben Collins-Sussman wrote:
>>> Our solution:
>>> Over at Google, we simply hacked APR to *never* hold on to blocks for
>>> recycling.  Essentially, this makes apr_pool_destroy() always free()
>>> the block, and makes apr_pool_create() always call malloc() malloc.
>>> Poof, all the memory leak went away instantly.
>>>
>> Why not creating allocator for each of those subpools.
>> On pool_destroy it'll destroy allocator and call free()
>> consuming the global pool only for allocating subpools
>> which are constant in size, thus no fragmentation can
>> occur.
> 
> The subversion libraries wrap all apr_pool_create and apr_pool_destroy
> calls in svn_pool_create and svn_pool_destroy functions.  I suppose we
> could make every svn_pool_create call use a new allocator, but I think
> a better solution is within APR itself -- perhaps a simple
> compile-time option which triggers this behavior in apr_pool_create.
> 

Within APR 1.3+ there is apr_pool_create_unmanaged that creates
allocator as well as part of the call.
However it needs to be explicitly destroyed, cause it doesn't
touch the global pool nor registers to any parent.
If you need that you can register a standard callback that will
destroy that pool explicitly on global or any parent destroy.


Regards
-- 
^(TM)