git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
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 13:00:45 -0400	[thread overview]
Message-ID: <Y1VzPY4zQyZbVAsm@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqqtu3vflau.fsf@gitster.g>

On Sat, Oct 22, 2022 at 05:14:33PM -0700, Junio C Hamano wrote:

> > Some options:
> >
> >   - find a different way to convince repack to die. The most likely is
> >     probably corrupting the cruft objects in some way such that
> >     pack-objects dies, but not until it starts doing real work.
> >
> >   - mark the test_must_fail with ok=sigpipe. In most case this is a
> >     band-aid, but here we still test what we want. The .tmp cleanup
> >     should kick in from a die() or from a signal death, so either is
> >     sufficient for our purposes.
> >
> >   - teach git-repack to ignore sigpipe. We don't actually check the
> >     writes to pack-objects (since they're done by fprintf), but we'd
> >     notice its failing exit code. And arguably this is improving the
> >     user experience. Saying "pack-objects died with an error" is more
> >     useful than a sigpipe.
> >
> > Thoughts?
> 
> I agree that for this particular one the second one is a reasonable
> thing to do in the context of the test.  The third one may actually
> be a better fix, exactly for the reason you state here.

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.

-- >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 &&
-- 
2.38.1.500.ge50734af7a


  reply	other threads:[~2022-10-23 17:00 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 [this message]
2022-10-23 18:08           ` Junio C Hamano
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=Y1VzPY4zQyZbVAsm@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    --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 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).