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: Sat, 22 Oct 2022 17:14:33 -0700	[thread overview]
Message-ID: <xmqqtu3vflau.fsf@gitster.g> (raw)
In-Reply-To: <Y1RUI8ny2mexxwKm@coredump.intra.peff.net> (Jeff King's message of "Sat, 22 Oct 2022 16:35:47 -0400")

Jeff King <peff@peff.net> writes:

> Ugh, I think this test is racy. I saw a failure via SIGPIPE on OS X in
> CI, and running it locally with --stress confirmed. I think the problem
> is in our method to trigger pack-objects to fail for the cruft pack. We
> pass a bogus command line argument, so pack-objects exits more or less
> immediately. But the parent git-repack process is trying to write to its
> stdin (to name packs to keep/exclude). So that write may succeed or fail
> based on how quickly the child dies.

Yeah, I saw flaky failures myself during my integration tests.

> 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.

Thanks.

  reply	other threads:[~2022-10-23  0:14 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 [this message]
2022-10-23 17:00         ` Jeff King
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=xmqqtu3vflau.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.