Subject: Re: [PATCH v2 2/2] Fix minor memory leak found by LeakSanitizer.

From: Junio C Hamano <[email-masked]>
Date: Thu, 24 Aug 2023 08:56:59 -0700

"Kevin Backhouse via GitGitGadget" <[email-masked]> writes:

> Subject: Re: [PATCH v2 2/2] Fix minor memory leak found by LeakSanitizer.

Continuing the review for the previous step, perhaps 

	Subject: [PATCH] merge: free list of merge bases upon failure

or something?

> From: Kevin Backhouse <[email-masked]>
>
> The callers of merge_recursive() and merge_ort_recursive() expects the

"expects" -> "expect"

> commit list passed in as the merge_bases parameter to be fully
> consumed by the function and does not free it when the function

"does not" -> "do not".

> returns.  In normal cases, the commit list does get consumed, but when
> the function returns early upon encountering an error, it forgets to
> clean it up.
>
> Fix this by freeing the list in the code paths for error returns.
>
> Signed-off-by: Kevin Backhouse <[email-masked]>
> ---

Well written to be understandable.  Nicely done.

>  merge-ort-wrappers.c |  4 +++-
>  merge-ort.c          |  4 +++-
>  merge-recursive.c    | 32 ++++++++++++++++++++++----------
>  3 files changed, 28 insertions(+), 12 deletions(-)
>
> diff --git a/merge-ort-wrappers.c b/merge-ort-wrappers.c
> index 4acedf3c338..aeb56c9970c 100644
> --- a/merge-ort-wrappers.c
> +++ b/merge-ort-wrappers.c
> @@ -54,8 +54,10 @@ int merge_ort_recursive(struct merge_options *opt,
>  	struct tree *head = repo_get_commit_tree(opt->repo, side1);
>  	struct merge_result tmp;
>  
> -	if (unclean(opt, head))
> +	if (unclean(opt, head)) {
> +		free_commit_list(merge_bases);
>  		return -1;
> +	}

OK.

> diff --git a/merge-ort.c b/merge-ort.c
> index 8631c997002..a0eb91fb011 100644
> --- a/merge-ort.c
> +++ b/merge-ort.c
> @@ -5070,8 +5070,10 @@ static void merge_ort_internal(struct merge_options *opt,
>  		opt->branch1 = "Temporary merge branch 1";
>  		opt->branch2 = "Temporary merge branch 2";
>  		merge_ort_internal(opt, NULL, prev, next, result);
> -		if (result->clean < 0)
> +		if (result->clean < 0) {
> +			free_commit_list(merge_bases);
>  			return;
> +		}

OK.

> diff --git a/merge-recursive.c b/merge-recursive.c
> index 6a4081bb0f5..49e54d3722f 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -3652,14 +3652,18 @@ static int merge_recursive_internal(struct merge_options *opt,
>  		opt->branch1 = "Temporary merge branch 1";
>  		opt->branch2 = "Temporary merge branch 2";
>  		if (merge_recursive_internal(opt, merged_merge_bases, iter->item,
> -					     NULL, &merged_merge_bases) < 0)
> -			return -1;
> +					     NULL, &merged_merge_bases) < 0) {
> +			clean = -1;
> +			goto out;
> +		}
>  		opt->branch1 = saved_b1;
>  		opt->branch2 = saved_b2;
>  		opt->priv->call_depth--;
>  
> -		if (!merged_merge_bases)
> -			return err(opt, _("merge returned no commit"));
> +		if (!merged_merge_bases) {
> +			clean = err(opt, _("merge returned no commit"));
> +			goto out;
> +		}
>  	}
>  
>  	/*
> @@ -3682,8 +3686,11 @@ static int merge_recursive_internal(struct merge_options *opt,
>  				     repo_get_commit_tree(opt->repo,
>  							  merged_merge_bases),
>  				     &result_tree);
> +
> +out:
>  	strbuf_release(&merge_base_abbrev);
>  	opt->ancestor = NULL;  /* avoid accidental re-use of opt->ancestor */
> +	free_commit_list(merge_bases);
>  	if (clean < 0) {
>  		flush_output(opt);
>  		return clean;

Hmph, so the proposed log message made it sound like the merge_bases
list is consumed fully in the normal non-error case, but even the
normal case was leaky on the "-s recursive" side?  Or was the
recursive side was OK and the caller had different expectations, in
which case we may be breaking them, but you poked at these codepaths
long enough to produce this patch, so I doubt it.  The proposed log
message needs to be updated to explain the findings on this side,
too, if the situation is different from the "ort" side.

> @@ -3729,6 +3736,9 @@ static int merge_start(struct merge_options *opt, struct tree *head)
>  	assert(!opt->record_conflict_msgs_as_headers);
>  	assert(!opt->msg_header_prefix);
>  
> +	CALLOC_ARRAY(opt->priv, 1);
> +	string_list_init_dup(&opt->priv->df_conflict_file_set);

This move, what it does, why it is needed, and what breaks without
it, is not explained in the proposed log message.

>  	/* Sanity check on repo state; index must match head */
>  	if (repo_index_has_changes(opt->repo, head, &sb)) {
>  		err(opt, _("Your local changes to the following files would be overwritten by merge:\n  %s"),
> @@ -3737,16 +3747,13 @@ static int merge_start(struct merge_options *opt, struct tree *head)
>  		return -1;
>  	}
>  
> -	CALLOC_ARRAY(opt->priv, 1);
> -	string_list_init_dup(&opt->priv->df_conflict_file_set);
>  	return 0;
>  }

>  static void merge_finalize(struct merge_options *opt)
>  {
>  	flush_output(opt);
> -	if (!opt->priv->call_depth && opt->buffer_output < 2)
> -		strbuf_release(&opt->obuf);
> +	strbuf_release(&opt->obuf);

Ditto.  Unconditional release here may help the new caller in
merge_trees() that failed merge_start(), but is the change safe for
other existing callers and if so why/how?

In any case, this needs a review by somebody more familiar with the
recursive backend machinery than myself.  Any takers?

>  	if (show(opt, 2))
>  		diff_warn_rename_limit("merge.renamelimit",
>  				       opt->priv->needed_rename_limit, 0);
> @@ -3763,8 +3770,10 @@ int merge_trees(struct merge_options *opt,
>  
>  	assert(opt->ancestor != NULL);
>  
> -	if (merge_start(opt, head))
> +	if (merge_start(opt, head)) {
> +		merge_finalize(opt);
>  		return -1;
> +	}
>  	clean = merge_trees_internal(opt, head, merge, merge_base, &ignored);
>  	merge_finalize(opt);
>  
> @@ -3785,8 +3794,11 @@ int merge_recursive(struct merge_options *opt,
>  	prepare_repo_settings(opt->repo);
>  	opt->repo->settings.command_requires_full_index = 1;
>  
> -	if (merge_start(opt, repo_get_commit_tree(opt->repo, h1)))
> +	if (merge_start(opt, repo_get_commit_tree(opt->repo, h1))) {
> +		free_commit_list(merge_bases);
> +		merge_finalize(opt);
>  		return -1;
> +	}

I suspect that the way leaks happen is different between "ort" and
"recursive", and what is in the proposed log message may have been
the right description of the problem back when the patch was only
about fixing "ort" but no longer is sufficient now that we also fix
the "recursive" side.

>  	clean = merge_recursive_internal(opt, h1, h2, merge_bases, result);
>  	merge_finalize(opt);

Hmph, but this does expect merge_bases is consumed in normal
codepath.  Now I am confused, sorry.

Thanks for working on this.