From: Jeff King <peff@peff.net>
To: lidongyan <502024330056@smail.nju.edu.cn>
Cc: Patrick Steinhardt <ps@pks.im>,
Lidong Yan via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH] pack-bitmap: add loading corrupt bitmap_index test
Date: Mon, 19 May 2025 03:39:49 -0400 [thread overview]
Message-ID: <20250519073949.GD102701@coredump.intra.peff.net> (raw)
In-Reply-To: <80BCF957-002B-4532-8E3D-8CAB45AC0349@smail.nju.edu.cn>
On Mon, May 19, 2025 at 02:44:22PM +0800, lidongyan wrote:
> 2025年5月19日 14:02,Patrick Steinhardt <ps@pks.im> 写道:
> > Okay. We _can_ do that now, but the patch doesn't explain why we
> > _should_.
>
> The main purpose of this patch is to provide a test case to check whether
> a memory leak occurs when loading a corrupt index file as requested here
> https://lore.kernel.org/git/20250514180325.GB2196784@coredump.intra.peff.net.
> A potential memory leak is mentioned in this patch here https://lore.kernel.org/git/pull.1962.git.git.1747052530271.gitgitgadget@gmail.com/.
I think we'd need to mark it with the !SANITIZE_LEAK prereq until the
leaks are actually fixed. Or simpler, just apply this on top of the leak
fixes once they are ready. That ordering needs to be communicated to the
maintainer, and the simplest way to do that is probably to just post a
3-patch series: your initial leak fix, a polished version of the one
from Taylor, and then the test on top.
> > My proposal would be to either move the logic into "test-bitmap.c", or
> > to even better to write a unit test in "t/unit-tests/". After all, we
> > expect that the code should fail gracefully, so a unit test might be a
> > good fit after all.
>
> I found that the header size of an index file depends only on the type of hash algorithm.
> To trigger the condition for the memory leak, I need to corrupt a few bytes right after the
> index file header size. It's more convenient to implement this functionality in pack-bitmap.c.
> However, I think I can place the test itself under t/unit-tests/.
I don't think you can do a prereq for a unit-test file (though I might
be wrong, as I have not really paid attention to that area).
If the corruption offsets are easy-ish to compute statically (and it
sounds like they mostly just depend on the hash algorithm size), then
I'd actually prefer to just do it with "dd". That avoids extra C code,
and simulates a real on-disk corruption more exactly (using real
commands).
Something like:
diff --git a/t/t5310-pack-bitmaps.sh b/t/t5310-pack-bitmaps.sh
index 042f62f16e..16bd607654 100755
--- a/t/t5310-pack-bitmaps.sh
+++ b/t/t5310-pack-bitmaps.sh
@@ -498,7 +498,17 @@ test_bitmap_cases () {
git commit -am "add hello_world.txt" &&
git repack -adb &&
- test-tool bitmap load-corrupt
+ bitmap=$(ls .git/objects/pack/pack-*.bitmap) &&
+ chmod +w "$bitmap" &&
+
+ # this matches the xor offset
+ offset=$((120 + $(test_oid rawsz))) &&
+ printf "\241" |
+ dd of=$bitmap count=1 bs=1 conv=notrunc seek=$offset &&
+
+ git rev-list --count HEAD >expect &&
+ git rev-list --use-bitmap-index --count HEAD >actual &&
+ test_cmp expect actual
)
'
}
-Peff
next prev parent reply other threads:[~2025-05-19 7:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-17 14:26 [PATCH] pack-bitmap: add loading corrupt bitmap_index test Lidong Yan via GitGitGadget
2025-05-19 6:02 ` Patrick Steinhardt
2025-05-19 6:44 ` lidongyan
2025-05-19 7:27 ` Patrick Steinhardt
2025-05-19 7:37 ` lidongyan
2025-05-19 7:39 ` Jeff King [this message]
2025-05-19 7:58 ` lidongyan
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=20250519073949.GD102701@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=502024330056@smail.nju.edu.cn \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=ps@pks.im \
/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