All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/3] cache-tree: detect mismatching number of index entries
Date: Wed, 18 Sep 2024 18:35:35 -0700	[thread overview]
Message-ID: <xmqqttec8ly0.fsf@gitster.g> (raw)
In-Reply-To: <595693a6420b2571aabd51ed989bedfa0cfa62e2.1726556195.git.ps@pks.im> (Patrick Steinhardt's message of "Tue, 17 Sep 2024 09:13:11 +0200")

Patrick Steinhardt <ps@pks.im> writes:

> +	if (it->entry_count + pos > istate->cache_nr) {
> +		ret = error(_("corrupted cache-tree has entries not present in index"));
> +		goto out;
> +	}

Is it a safe assumption that the if() condition always indicates an
error?  When sparse-index is in effect, istate->cache_nr may be a
number that is smaller than the true number of paths in the index
(because all paths under a subdirectory we are not interested in are
folded into a single tree-ish entry), and I am not sure how it
should interact with it->entry_count (i.e. the number of paths under
the current directory we are looking at, which obviously cannot be a
sparsified entry) and pos (i.e. the index into active_cache[] that
represend the first path under the current directory)?

I guess as long as "it" is not folded, it does not matter how other
paths from different directories in active_cache[] are sparsified or
expanded, as long as "pos" keeps track of the current position
correctly.

> diff --git a/t/t4058-diff-duplicates.sh b/t/t4058-diff-duplicates.sh
> index 2501c89c1c9..3f602adb055 100755
> --- a/t/t4058-diff-duplicates.sh
> +++ b/t/t4058-diff-duplicates.sh
> @@ -132,15 +132,15 @@ test_expect_success 'create a few commits' '
>  	rm commit_id up final
>  '
>  
> -test_expect_failure 'git read-tree does not segfault' '
> -	test_when_finished rm .git/index.lock &&
> -	test_might_fail git read-tree --reset base
> +test_expect_success 'git read-tree does not segfault' '
> +	test_must_fail git read-tree --reset base 2>err &&
> +	test_grep "error: corrupted cache-tree has entries not present in index" err
>  '

Very good.  test_might_fail is a sign of trouble, and this gives us
a lot more predictability.

  reply	other threads:[~2024-09-19  1:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-17  7:13 [PATCH 0/3] cache-tree: fix segfaults with invalid cache-trees Patrick Steinhardt
2024-09-17  7:13 ` [PATCH 1/3] cache-tree: refactor verification to return error codes Patrick Steinhardt
2024-09-17 17:05   ` Eric Sunshine
2024-09-18  5:11     ` Patrick Steinhardt
2024-09-17  7:13 ` [PATCH 2/3] cache-tree: detect mismatching number of index entries Patrick Steinhardt
2024-09-19  1:35   ` Junio C Hamano [this message]
2024-09-24  6:48     ` Patrick Steinhardt
2024-09-24 17:01       ` Junio C Hamano
2024-09-17  7:13 ` [PATCH 3/3] unpack-trees: detect mismatching number of cache-tree/index entries Patrick Steinhardt
2024-10-07  4:38 ` [PATCH v2 0/3] cache-tree: fix segfaults with invalid cache-trees Patrick Steinhardt
2024-10-07  4:38   ` [PATCH v2 1/3] cache-tree: refactor verification to return error codes Patrick Steinhardt
2024-10-07  4:38   ` [PATCH v2 2/3] cache-tree: detect mismatching number of index entries Patrick Steinhardt
2024-10-07  4:38   ` [PATCH v2 3/3] unpack-trees: detect mismatching number of cache-tree/index entries Patrick Steinhardt

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=xmqqttec8ly0.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.