Re: apr pools & memory leaks

[Mladen Turk]

Ben Collins-Sussman wrote:

On Thu, Oct 2, 2008 at 2:44 AM, Mladen Turk <[EMAIL PROTECTED]> 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)