RE: [BUG] 2.44.0 t7704.9 Fails on NonStop ia64

[<rsbecker@nexbridge.com>]

On Monday, February 26, 2024 10:32 AM, Philip Wood wrote:
>On 25/02/2024 20:36, rsbecker@nexbridge.com wrote:
>> On Sunday, February 25, 2024 2:20 PM, Torsten Bögershausen wrote:
>>> On Sun, Feb 25, 2024 at 02:08:35PM -0500, rsbecker@nexbridge.com wrote:
>>>> On Sunday, February 25, 2024 1:45 PM, I wrote:
>>>>> To: git@vger.kernel.org
>>> But I think that this should be used:
>>> write_in_full()
>>
>> My mailer autocorrected, yes, xwrite. write_in_full() would be safe,
>> although a bit redundant since xwrite() does similar things and is
>> used by write_in_full().
>
>Note that unlike write_in_full(), xwrite() does not guarantee to write the whole
>buffer passed to it. In general unless a caller is writing a single byte or writing less
>than PIPE_BUF bytes to a pipe it should use write_in_full().
>
>> The question is which call is bad? The cruft stuff is relatively new
>> and I don't know the code.
>>
>>>> reftable/writer.c:              int n = w->write(w->write_arg, zeroed,
>>>> w->pending_padding);
>>>> reftable/writer.c:      n = w->write(w->write_arg, data, len);
>
>Neither of these appear to check for short writes and
>reftable_fd_write() is a thin wrapper around write(). Maybe
>reftable_fd_write() should be using write_in_full()?
>
>>>> run-command.c:                  len = write(io->fd, io->u.out.buf,
>
>This call to write() looks correct as it is in the io pump loop.
>
>>>> t/helper/test-path-utils.c:                     if (write(1, buffer,
>> count)
>>>> < 0) >>> t/helper/test-windows-named-pipe.c:             write(1, buf, nbr);
>>>> t/helper/test-windows-named-pipe.c:             write(1, buf, nbr);
>
>In principle these all look like they are prone to short writes.
>
>>>> trace2/tr2_dst.c:       bytes = write(fd, buf_line->buf, buf_line->len);
>
>This caller explicitly says it prefers short writes over retrying

The real issue is that t7704.9 fails as follows:

Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0) Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), done.
Total 3 (delta 0), reused 3 (delta 0), pack-reused 0 (from 0)
ls: cannot access '.git/objects/pack/pack-*.mtimes': No such file or directory
test_line_count: line count for cruft.after != 2 not ok 9 - --max-cruft-size with pruning #

So something is not writing the mtimes file correctly. That's what I am trying to track down. The write issue is a possible cause but not necessarily the root cause.

--Randall