git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>,
	git@vger.kernel.org, Taylor Blau <me@ttaylorr.com>
Subject: Re: [PATCH] test_bitmap_hashes(): handle repository without bitmaps
Date: Fri, 5 Nov 2021 15:11:11 -0400	[thread overview]
Message-ID: <YYWBz6rjF+I+JkO3@nand.local> (raw)
In-Reply-To: <xmqq35oaxwnz.fsf@gitster.g>

On Fri, Nov 05, 2021 at 11:52:16AM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > If prepare_bitmap_git() returns NULL (one easy-to-trigger cause being
> > that the repository does not have bitmaps at all), then we'll segfault
> > accessing bitmap_git->hashes:
> >
> >   $ t/helper/test-tool bitmap dump-hashes
> >   Segmentation fault
> >
> > We should treat this the same as a repository with bitmaps but no
> > name-hashes, and quietly produce an empty output. The later call to
> > free_bitmap_index() in the cleanup label is OK, as it treats a NULL
> > pointer as a noop.
> >
> > This isn't a big deal in practice, as this function is intended for and
> > used only by test-tool. It's probably worth fixing to avoid confusion,
> > but not worth adding coverage for this to the test suite.
> >
> > Signed-off-by: Jeff King <peff@peff.net>
> > ---
> > This is new in the v2.34.0 cycle, but it's so low impact it doesn't
> > matter much if we ship with the bug. OTOH, it's pretty low-risk since it
> > is only run by the test suite.
>
> ;-)

Yes, this looks obviously correct to me. Thanks for spotting and fixing
this, Peff.

I'd be happy to see it in the 2.34 cycle, too, but I agree that it would
be OK if it didn't make the cut (and certainly if it makes it easier for
Junio to handle the rest of the release cycle, then I'm in favor of
leaving it out).

> I wonder how you found it.  Diagnosing a repository that did not
> seem healthy?  What I am getting at is if we want a new option to
> make a plumbing command, other than the test-tool, that calls this
> function, as the latter is usually not deployed in the field.

I would not be surprised if this was discovered via Coverity, or by
manual inspection. Peff and I have been merging a slew of releases from
your tree into GitHub's fork and so have been reading code in the more
recently changed areas.

On the test-tool vs. plumbing thing: I think there are some compelling
reasons in either direction. There's no *good* home for these in our
current set of plumbing tools. E.g., the closest example we have is `git
rev-list --test-bitmap <rev>`, which is kind of ugly. When we needed
these new inspection tools for some of the newer bitmap-related tests,
adding them via the test-helper suite was a conscious choice to not
build on the ugliness of `--test-bitmap`.

But on occasion these test-tool things are useful to have "in the
field", as you say. It's rare enough that I usually just clone a copy of
our fork as needed and build it when I do find myself reaching for
test-helpers.

Thanks,
Taylor

  reply	other threads:[~2021-11-05 19:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-05  9:01 [PATCH] test_bitmap_hashes(): handle repository without bitmaps Jeff King
2021-11-05 18:52 ` Junio C Hamano
2021-11-05 19:11   ` Taylor Blau [this message]
2021-11-05 23:29     ` Jeff King
2021-11-06  4:08     ` move some test-tools to 'unstable plumbing' built-ins (was: [PATCH] test_bitmap_hashes(): handle repository without bitmaps) Ævar Arnfjörð Bjarmason
2021-11-07 17:06       ` Taylor Blau
2021-11-08 19:16         ` move some test-tools to 'unstable plumbing' built-ins Junio C Hamano
2021-11-08 20:19           ` Ævar Arnfjörð Bjarmason
2021-11-08 22:06             ` Taylor Blau

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YYWBz6rjF+I+JkO3@nand.local \
    --to=me@ttaylorr.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).