On Fri, 2003-12-12 at 12:44, Sander Striker wrote:
> > + /* Yes, opening a repository registers a cleanup on the pool from
> > + which we are already running as a cleanup. But these days that's
> > + safe. A big +smooch+ to Sander Striker -- I'm not sure it was
> > + he who implemented this, but he told me about it anyway :-). */
>
> And now he finally remembers why it was a bad idea to have cleanups
> do creation of objects instead of only tear-down. But, fortunately
> there is a workaround. And possibly this warrants a change in the
> pools code.
>
> Straight from apr_pools.c (line 1398):
>
> /* Run cleanups */
> run_cleanups(&pool->cleanups);
> pool->cleanups = NULL;
>
> /* If new child pools showed up, this is a reason to raise a flag */
> if (pool->child)
> abort();
>
> Now, this is in the debug code, in the production code, new child
> pools are simply ignored == memory leaks (and possible resource
> leaks).
>
> The gist is: it is ok to do allocations in the pool that's being cleaned
> up. It is also ok to register cleanups against that pool. It is
> not ok to create subpools of the pool being cleaned up, _unless_
> the cleanup destroys the subpools after it is done. IOW, a cleanup
> has to clean up after itself. Simple workaround: create a subpool
> of cdb->pool, pass that to svn_repos_open and svn_fs_deltify_revision,
> destroy the subpool at the end of the cleanup.
This may be a non-issue, while combing through the code it seems that
each subpool created is also destroyed. Nevertheless it would be
safer to create and destroy that subpool in the cleanup, to be 100%
sure, now and in the future, that the cleanup doesn't leave anything
behind.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 12 13:51:13 2003