From: Junio C Hamano <gitster@pobox.com>
To: "Kevin Backhouse via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Kevin Backhouse <kevinbackhouse@github.com>
Subject: Re: [PATCH v2 2/2] Fix minor memory leak found by LeakSanitizer.
Date: Thu, 24 Aug 2023 08:56:59 -0700 [thread overview]
Message-ID: <xmqqv8d4bfhw.fsf@gitster.g> (raw)
In-Reply-To: <353e1960b4466912c508733e5a7eb80884cd9bdd.1692886365.git.gitgitgadget@gmail.com> (Kevin Backhouse via GitGitGadget's message of "Thu, 24 Aug 2023 14:12:45 +0000")
"Kevin Backhouse via GitGitGadget" <gitgitgadget@gmail.com> 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 <kevinbackhouse@github.com>
>
> 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 <kevinbackhouse@github.com>
> ---
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.
prev parent reply other threads:[~2023-08-24 15:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-18 20:04 [PATCH] This fixes a minor memory leak (detected by LeakSanitizer) in git merge Kevin Backhouse via GitGitGadget
2023-08-18 21:41 ` Junio C Hamano
2023-09-12 15:06 ` Elijah Newren
2023-08-24 14:12 ` [PATCH v2 0/2] " Kevin Backhouse via GitGitGadget
2023-08-24 14:12 ` [PATCH v2 1/2] Regression test for https://github.com/gitgitgadget/git/pull/1577 Kevin Backhouse via GitGitGadget
2023-08-24 15:11 ` Junio C Hamano
2023-08-24 14:12 ` [PATCH v2 2/2] Fix minor memory leak found by LeakSanitizer Kevin Backhouse via GitGitGadget
2023-08-24 15:56 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqv8d4bfhw.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=kevinbackhouse@github.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).