Philip Martin wrote:
> Build the branch with pool debugging on APR and tests fail on the merge
> operation with:
>
> apr_hash_merge: overlay's pool is not an ancestor of p
> Aborted
>
Thanks for finding that, Philip. It looks to me like there must be
something wrong inside the loop if it cares where its iterpool is allocated
from. Would you kindly commit any fix that you find satisfactory, please,
bearing in mind that the priority for this tool is to be simple to hack on
rather than efficient and scalable. (For example, if the easiest fix is to
get rid of the iterpool, then so be it -- that's good enough.)
- Julian
> The problem is the pattern used to create svnmover_wc_t objects: a
> result pool is passed to wc_create(), a subpool is created and the
> object and its data are alocated in that subpool. Later when execute()
> calls svn_branch_merge() it passes data allocated in that subpool but
> the scratch_pool that also gets passed is a sibling not a descendant of
> that pool.
>
> A simple fix is
>
> Index: ../src2/subversion/svnmover/svnmover.c
> ===================================================================
> --- ../src2/subversion/svnmover/svnmover.c (revision 1690117)
> +++ ../src2/subversion/svnmover/svnmover.c (working copy)
> @@ -2523,7 +2523,7 @@
> {
> svn_editor3_t *editor;
> const char *base_relpath;
> - apr_pool_t *iterpool = svn_pool_create(pool);
> + apr_pool_t *iterpool = svn_pool_create(wc->pool);
> int i;
>
> editor = wc->editor;
>
> I think allocating the subpool in wc_create() is a bit of an
> anti-pattern, it takes pool management away from the caller. Simply
> eliminating the subpool is not a fix unless final_commit() is also
> changed to not destroy the svnmover_wc_t pool.
>
> --
> Philip Martin
> WANdisco
>
Received on 2015-07-09 19:34:59 CEST