From: Junio C Hamano <gitster@pobox.com>
To: "Lidong Yan via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Patrick Steinhardt <ps@pks.im>,
Eric Sunshine <sunshine@sunshineco.com>,
Taylor Blau <me@ttaylorr.com>,
Lidong Yan <502024330056@smail.nju.edu.cn>
Subject: Re: [PATCH v5] pack-bitmap: remove checks before bitmap_free
Date: Thu, 05 Jun 2025 08:29:01 -0700 [thread overview]
Message-ID: <xmqqldq69phe.fsf@gitster.g> (raw)
In-Reply-To: <pull.1977.v5.git.git.1749104667618.gitgitgadget@gmail.com> (Lidong Yan via GitGitGadget's message of "Thu, 05 Jun 2025 06:24:27 +0000")
"Lidong Yan via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Lidong Yan <502024330056@smail.nju.edu.cn>
>
> In pack-bitmap.c:find_boundary_objects(), the roots_bitmap is only freed
> if cascade_pseudo_merges_1() fails. Since cascade_pseudo_merges_1() only
> use roots_bitmap as a mutable reference but not takes roots_bitmap's
> ownership. Once cascade_pseudo_merges_1 succeed(), roots_bitmap leaks.
"Once cascade_pseudo_merges_1() succeeds", perhaps?
> And this leak currently lacks a dedicated test to detect it.
>
> To fix this leak, remove if cascade_pseudo_merges_1() succeed check and
> always calling bitmap_free(roots_bitmap);
>
> To trigger this leak, we need roots_bitmap contains at least one pseudo
> merge.
"contains" -> "that contains"?
> diff --git a/pack-bitmap.c b/pack-bitmap.c
> index ac6d62b980c..8727f316de9 100644
> --- a/pack-bitmap.c
> +++ b/pack-bitmap.c
> @@ -1363,8 +1363,8 @@ static struct bitmap *find_boundary_objects(struct bitmap_index *bitmap_git,
> bitmap_set(roots_bitmap, pos);
> }
>
> - if (!cascade_pseudo_merges_1(bitmap_git, cb.base, roots_bitmap))
> - bitmap_free(roots_bitmap);
> + cascade_pseudo_merges_1(bitmap_git, cb.base, roots_bitmap);
> + bitmap_free(roots_bitmap);
This makes it as if the original _wanted_ to leak it when the call
failed. Readers may wonder how we got into this state in the first
place. Was it a simple thinko when 11d45a6e (pack-bitmap.c: use
pseudo-merges during traversal, 2024-05-23) was written, I have to
wonder.
> diff --git a/t/t5333-pseudo-merge-bitmaps.sh b/t/t5333-pseudo-merge-bitmaps.sh
> index 56674db562f..ba5ae6a00c9 100755
> --- a/t/t5333-pseudo-merge-bitmaps.sh
> +++ b/t/t5333-pseudo-merge-bitmaps.sh
> @@ -445,4 +445,21 @@ test_expect_success 'pseudo-merge closure' '
> )
> '
>
> +test_expect_success 'use pseudo-merge in boundary traversal' '
> + git init pseudo-merge-boundary-traversal &&
> + (
> + cd pseudo-merge-boundary-traversal &&
> +
> + git config bitmapPseudoMerge.test.pattern refs/ &&
> + git config pack.useBitmapBoundaryTraversal true &&
Yup, this is a temporary repository for only this test, so using
"git config" there makes it the simplest and the easiest to
understand.
> + test_commit A &&
> + git repack -adb &&
> + test_commit B &&
> +
> + nr=$(git rev-list --count --use-bitmap-index HEAD~1..HEAD) &&
> + test 1 -eq "$nr"
> + )
> +'
> +
> test_done
>
> base-commit: 845c48a16a7f7b2c44d8cb137b16a4a1f0140229
next prev parent reply other threads:[~2025-06-05 15:29 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-25 5:09 [PATCH] pack-bitmap: remove checks before bitmap_free Lidong Yan via GitGitGadget
2025-05-26 6:49 ` Patrick Steinhardt
2025-05-26 16:05 ` lidongyan
2025-05-30 18:14 ` [PATCH v2 0/2] " Lidong Yan via GitGitGadget
2025-05-30 18:14 ` [PATCH v2 1/2] " Lidong Yan via GitGitGadget
2025-05-30 18:14 ` [PATCH v2 2/2] t5333: test memory leak when use pseudo-merge in boundary traversal Lidong Yan via GitGitGadget
2025-05-30 21:42 ` Junio C Hamano
2025-05-30 21:50 ` Eric Sunshine
2025-05-31 3:18 ` lidongyan
2025-05-30 21:06 ` [PATCH v2 0/2] pack-bitmap: remove checks before bitmap_free Junio C Hamano
2025-06-03 1:46 ` [PATCH v3] " Lidong Yan via GitGitGadget
2025-06-03 6:12 ` Junio C Hamano
2025-06-03 6:22 ` lidongyan
2025-06-03 15:14 ` Junio C Hamano
2025-06-03 15:32 ` lidongyan
2025-06-04 12:32 ` Junio C Hamano
2025-06-04 12:43 ` lidongyan
2025-06-04 14:49 ` Junio C Hamano
2025-06-03 6:20 ` [PATCH v4] " Lidong Yan via GitGitGadget
2025-06-03 22:09 ` Taylor Blau
2025-06-04 2:50 ` lidongyan
2025-06-05 6:24 ` [PATCH v5] " Lidong Yan via GitGitGadget
2025-06-05 15:29 ` Junio C Hamano [this message]
2025-06-10 5:58 ` lidongyan
2025-06-05 15:53 ` [PATCH v6] " Lidong Yan via GitGitGadget
2025-06-06 1:28 ` Junio C Hamano
2025-06-06 5:49 ` lidongyan
2025-06-09 8:18 ` [PATCH v7] " Lidong Yan via GitGitGadget
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=xmqqldq69phe.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=502024330056@smail.nju.edu.cn \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=me@ttaylorr.com \
--cc=ps@pks.im \
--cc=sunshine@sunshineco.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).