Re: apr pools & memory leaks

Ben Collins-Sussman wrote:
> On Thu, Oct 2, 2008 at 2:44 AM, Mladen Turk <mturk_at_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)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org