git/list[1] front-page[2] threads[3] people[4] search[5] about
 

RE: [PATCH v2 3/3] builtin/unpack-objects.c: change xwrite to write_in_full avoid truncation.

From
rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date
Feb 27, 2024, 21:05 UTC
Message-ID
<03d701da69c0$c3430e80$49c92b80$@nexbridge.com>
In-Reply-To
<20240227192530.GD3784114@coredump.intra.peff.net>
On Tuesday, February 27, 2024 2:26 PM, Peff wrote:
Show 55 quoted lines
>To: rsbecker@nexbridge.com
>Cc: 'Junio C Hamano' <gitster@pobox.com>; 'Randall S. Becker' <the.n.e.key@gmail.com>; git@vger.kernel.org
>Subject: Re: [PATCH v2 3/3] builtin/unpack-objects.c: change xwrite to write_in_full avoid truncation.
>
>On Tue, Feb 27, 2024 at 02:04:46PM -0500, rsbecker@nexbridge.com wrote:
>
>> >> diff --git a/builtin/unpack-objects.c b/builtin/unpack-objects.c
>> >> index e0a701f2b3..6935c4574e 100644
>> >> --- a/builtin/unpack-objects.c
>> >> +++ b/builtin/unpack-objects.c
>> >> @@ -680,7 +680,7 @@ int cmd_unpack_objects(int argc, const char
>> >> **argv, const char *prefix UNUSED)
>> >>
>> >>  	/* Write the last part of the buffer to stdout */
>> >>  	while (len) {
>> >> -		int ret = xwrite(1, buffer + offset, len);
>> >> +		int ret = write_in_full(1, buffer + offset, len);
>> >>  		if (ret <= 0)
>> >>  			break;
>> >>  		len -= ret;
>> [...]
>> I experimented with using write_in_full vs. keeping xwrite. With
>> xwrite in this loop, t7704.9 consistently fails as described in the
>> other thread. With write_in_full, the code works correctly. I assume
>> there are side-effects that are present. This change is critical to
>> having the code work on NonStop. Otherwise git seems to be at risk of
>> actually being seriously broken if unpack does not work correctly. I
>> am happy to have my series ignored as long as the problem is otherwise corrected.
>
>I'm somewhat skeptical that this code is to blame, as it should be run very rarely at all; it is just dumping any content in the pack stream
>after the end of the checksum to stdout. But in normal use by Git, there is no such content in the first place.
>
>If I do this:
>
>diff --git a/builtin/unpack-objects.c b/builtin/unpack-objects.c index e0a701f2b3..affe55035d 100644
>--- a/builtin/unpack-objects.c
>+++ b/builtin/unpack-objects.c
>@@ -680,11 +680,7 @@ int cmd_unpack_objects(int argc, const char **argv, const char *prefix UNUSED)
>
> 	/* Write the last part of the buffer to stdout */
> 	while (len) {
>-		int ret = xwrite(1, buffer + offset, len);
>-		if (ret <= 0)
>-			break;
>-		len -= ret;
>-		offset += ret;
>+		BUG("cruft at the end of the pack!");
> 	}
>
> 	/* All done */
>
>then t7704 still passes, as it does not run this code at all. In fact, nothing in the test suite fails. Which is not to say we should get rid of
>those code. If we were writing today we might flag it as an error, but we should keep it for historical compatibility.
>
>But I do not see any bug in the code, and nor do I think it could contribute to a test failure.
I have obviously gone down the wrong path trying to resolve this situation. Please consider this entire series dropped with my apologies for the time-waste.
Unfortunately, I do not have sufficient knowledge of the code to resolve the originally reported problem without further assistance to determine the root case (assuming it still is a problem). Changes in master post-2.44.0 appear to have contributed to resolving the situation, so I am now getting random pass/fail on the test. I'm going to hold 2.44.0 on ia64 and wait for a subsequent release at retest at that time.

Sadly, --Randall

Previous: Jeff KingNext: Jeff King
Message 10 of 12 in “Change xwrite() to write_in_full() in builtins.”
  1. 0/2 Change xwrite() to write_in_full() in builtins.Randall S. Becker, Feb 27, 2024
  2. 1/3 builtin/repack.c: change xwrite to write_in_full and report errors.Randall S. Becker, Feb 27, 2024
  3. Junio C HamanoFeb 27, 2024
  4. 2/3 builtin/receive-pack.c: change xwrite to write_in_full.Randall S. Becker, Feb 27, 2024
  5. Junio C HamanoFeb 27, 2024
  6. 3/3 builtin/unpack-objects.c: change xwrite to write_in_full avoid truncation.Randall S. Becker, Feb 27, 2024
  7. Junio C HamanoFeb 27, 2024
  8. rsbecker@nexbridge.comFeb 27, 2024
  9. Jeff KingFeb 27, 2024
  10. rsbecker@nexbridge.comFeb 27, 2024
  11. Jeff KingMar 7, 2024
  12. rsbecker@nexbridge.comFeb 27, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.