All of lore.kernel.org
 help / color / mirror / Atom feed
From: <rsbecker@nexbridge.com>
To: "'Jeff King'" <peff@peff.net>
Cc: "'Git List'" <git@vger.kernel.org>
Subject: RE: [Bug] Test 1450.91 Fails on NonStop
Date: Wed, 15 Feb 2023 13:49:50 -0500	[thread overview]
Message-ID: <000801d9416e$4bf844b0$e3e8ce10$@nexbridge.com> (raw)
In-Reply-To: <Y+0eIlsIxRr+1RYp@coredump.intra.peff.net>

On Wednesday, February 15, 2023 1:02 PM, Jeff King wrote:
>On Wed, Feb 15, 2023 at 12:44:59PM -0500, rsbecker@nexbridge.com wrote:
>
>> + + git hash-object -w --stdin
>> + test-tool genzeros 104857601
>> blob=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
>
>That's not right. e69de29bb is the empty blob. A hundred megabytes (plus
>one) of zeroes should be d748d1b68b9dc69c4717ebc070dbc547d129bcc6.
>
>So that is the root of your problem (the empty file will obviously not trigger the "too
>large" fsck check), but I don't know why it would be failing.
>
>Maybe check the output of "test-tool genzeros 104857601" to make sure that it as
>expected? If not, then the bug is somewhere in t/helper/test-genzeros.c.
>
>It's on the left-hand side of pipe. Maybe it is getting a write() error, but we are
>ignoring it? Maybe a patch like this would help diagnose:
>
>diff --git a/t/helper/test-genzeros.c b/t/helper/test-genzeros.c index
>8ca988d621..0574917005 100644
>--- a/t/helper/test-genzeros.c
>+++ b/t/helper/test-genzeros.c
>@@ -18,14 +18,14 @@ int cmd__genzeros(int argc, const char **argv)
> 	/* Writing out individual NUL bytes is slow... */
> 	while (count < 0)
> 		if (write(1, zeros, ARRAY_SIZE(zeros)) < 0)
>-			return -1;
>+			die_errno("write()");
>
> 	while (count > 0) {
> 		n = write(1, zeros, count < ARRAY_SIZE(zeros) ?
> 			  count : ARRAY_SIZE(zeros));
>
> 		if (n < 0)
>-			return -1;
>+			die_errno("write()");
>
> 		count -= n;
> 	}
>

So, this looks like we do not have to hold the 2.39.2 release for this problem. I will run the packaging job for the platform release.

+ test-tool genzeros 104857601
fatal: write(): Invalid function argument

That explains it. We had to push the use of xwrite() because of issues associated with writing large buffers exceeding through write(). We could use MAX_IO_SIZE to limit the write size (at least on NonStop) into acceptable chunks.




  reply	other threads:[~2023-02-15 18:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-15 17:44 [Bug] Test 1450.91 Fails on NonStop rsbecker
2023-02-15 17:59 ` rsbecker
2023-02-15 18:02 ` Jeff King
2023-02-15 18:49   ` rsbecker [this message]
2023-02-15 19:10     ` Junio C Hamano
2023-02-15 19:41       ` rsbecker
2023-02-15 19:59       ` Jeff King
2023-02-16  1:45         ` Junio C Hamano
2023-02-16  2:56           ` [PATCH] test-genzeros: avoid raw write(2) Junio C Hamano
2023-02-16  4:34             ` Jeff King
2023-02-16 16:09               ` Junio C Hamano
2023-02-16 16:14                 ` rsbecker

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='000801d9416e$4bf844b0$e3e8ce10$@nexbridge.com' \
    --to=rsbecker@nexbridge.com \
    --cc=git@vger.kernel.org \
    --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.
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.