[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: memory pool problem in merge

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Mon, 21 Nov 2011 12:12:56 +0000

Philip Martin <philip.martin_at_wandisco.com> writes:

> This hack fixes the problem:
> Index: subversion/libsvn_client/merge.c
> ===================================================================
> --- subversion/libsvn_client/merge.c (revision 1203766)
> +++ subversion/libsvn_client/merge.c (working copy)
> @@ -593,6 +593,7 @@ tree_conflict(merge_cmd_baton_t *merge_b,
> if (merge_b->conflicted_paths == NULL)
> merge_b->conflicted_paths = apr_hash_make(merge_b->pool);
> + victim_abspath = apr_pstrdup(merge_b->pool, victim_abspath);
> apr_hash_set(merge_b->conflicted_paths, victim_abspath,
> APR_HASH_KEY_STRING, victim_abspath);
> }
> but I think the real fix is to identify which call to tree_conflict is
> passing victim_path with the wrong lifetime.

So I have to fix two callers to get the test to pass under valgrind:
merge_file_deleted:2078 and merge_dir_deleted:2424. There are lots of
other callers of tree_conflict that don't appear to duplicate the path,
including some in merge_file_deleted and merge_dir_deleted, and I don't
need to change them to avoid valgrind error. This is partly because the
regression tests don't cover all the code paths, but some of the other
callers are invoked and don't have to change.

So I don't know what to do. Is tree_conflict responsible for
duplicating the path, or is the caller responsible? There is also
tree_conflict_on_add which is very similar.

uberSVN: Apache Subversion Made Easy
Received on 2011-11-21 13:13:39 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.