All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, "Jan Pokorný" <poki@fnusa.cz>,
	"Taylor Blau" <me@ttaylorr.com>
Subject: Re: [PATCH v2 4/5] repack: use tempfiles for signal cleanup
Date: Sun, 23 Oct 2022 11:08:26 -0700	[thread overview]
Message-ID: <xmqqlep6fm5h.fsf@gitster.g> (raw)
In-Reply-To: <Y1VzPY4zQyZbVAsm@coredump.intra.peff.net> (Jeff King's message of "Sun, 23 Oct 2022 13:00:45 -0400")

Jeff King <peff@peff.net> writes:

> Here's a patch on top of of jk/repack-tempfile-cleanup that adjusts the
> test (and should make the immediate racy CI pain go away). It gives some
> explanation why the third option isn't as interesting as you'd think. If
> somebody later wants to add such a "pack-objects died" error, we can
> adjust sigpipe handling there.

An extremely simplified alternative would be just to say !  instead
of test_must_fail, which essentially is ok=anycrash ;-)

I did try the same exact patch before going to bed last night but
t7700 somehow failed some other steps in my local tests and I gave
up digging further X-<.  One step at a time...

Will queue.  Thanks.

> -- >8 --
> Subject: [PATCH] t7700: annotate cruft-pack failure with ok=sigpipe
>
> One of our tests intentionally causes the cruft-pack generation phase of
> repack to fail, in order to stimulate an exit from repack at the desired
> moment. It does so by feeding a bogus option argument to pack-objects.
> This is a simple and reliable way to get pack-objects to fail, but it
> has one downside: pack-objects will die before reading its stdin, which
> means the caller repack may racily get SIGPIPE writing to it.
>
> For the purposes of this test, that's OK. We are checking whether repack
> cleans up already-created .tmp files, and it will do so whether it exits
> or dies by signal (because the tempfile API hooks both).
>
> But we have to tell test_must_fail that either outcome is OK, or it
> complains about the signal. Arguably this is a workaround (compared to
> fixing repack), as repack dying to SIGPIPE means that it loses the
> opportunity to give a more detailed message. But we don't actually write
> such a message anyway; we rely on pack-objects to have written something
> useful to stderr, and it does. In either case (signal or exit), that is
> the main thing the user will see.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>  t/t7700-repack.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
> index edcda849b9..9164acbe02 100755
> --- a/t/t7700-repack.sh
> +++ b/t/t7700-repack.sh
> @@ -433,7 +433,7 @@ test_expect_success TTY '--quiet disables progress' '
>  '
>  
>  test_expect_success 'clean up .tmp-* packs on error' '
> -	test_must_fail git \
> +	test_must_fail ok=sigpipe git \
>  		-c repack.cruftwindow=bogus \
>  		repack -ad --cruft &&
>  	find $objdir/pack -name '.tmp-*' >tmpfiles &&

  reply	other threads:[~2022-10-23 18:08 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-21 21:41 [PATCH 0/4] repack tempfile-cleanup signal deadlock Jeff King
2022-10-21 21:42 ` [PATCH 1/4] repack: convert "names" util bitfield to array Jeff King
2022-10-21 22:19   ` Junio C Hamano
2022-10-21 23:10   ` Taylor Blau
2022-10-21 23:29     ` Jeff King
2022-10-21 23:35       ` Junio C Hamano
2022-10-21 23:43         ` Jeff King
2022-10-21 23:51           ` Junio C Hamano
2022-10-22  0:12             ` Jeff King
2022-10-21 21:43 ` [PATCH 2/4] repack: populate extension bits incrementally Jeff King
2022-10-21 23:20   ` Taylor Blau
2022-10-21 23:34     ` Jeff King
2022-10-21 23:41       ` Taylor Blau
2022-10-21 23:42       ` Jeff King
2022-10-21 21:46 ` [PATCH 3/4] repack: use tempfiles for signal cleanup Jeff King
2022-10-21 22:30   ` Junio C Hamano
2022-10-21 23:24     ` Jeff King
2022-10-21 23:45       ` Taylor Blau
2022-10-22  0:12         ` Jeff King
2022-10-22  0:11       ` Jeff King
2022-10-21 21:48 ` [PATCH 4/4] repack: drop remove_temporary_files() Jeff King
2022-10-21 23:51   ` Taylor Blau
2022-10-22  0:21 ` [PATCH v2 0/5] repack tempfile-cleanup signal deadlock Jeff King
2022-10-22  0:21   ` [PATCH v2 1/5] repack: convert "names" util bitfield to array Jeff King
2022-10-22  0:21   ` [PATCH v2 2/5] repack: populate extension bits incrementally Jeff King
2022-10-22  0:21   ` [PATCH v2 3/5] repack: expand error message for missing pack files Jeff King
2022-10-22  0:21   ` [PATCH v2 4/5] repack: use tempfiles for signal cleanup Jeff King
2022-10-22 20:35     ` Jeff King
2022-10-23  0:14       ` Junio C Hamano
2022-10-23 17:00         ` Jeff King
2022-10-23 18:08           ` Junio C Hamano [this message]
2022-10-23 20:55             ` Jeff King
2022-10-23 21:48               ` Junio C Hamano
2022-10-22  0:21   ` [PATCH v2 5/5] repack: drop remove_temporary_files() Jeff King

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=xmqqlep6fm5h.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    --cc=peff@peff.net \
    --cc=poki@fnusa.cz \
    /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.