On Wed, Feb 15, 2023 at 11:10:14AM -0800, Junio C Hamano wrote: > > + 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. > > True. > > Curious that this use of write(2) is from late 2021 and its uses in > tests came from the same era (e.g. t1051 has two calls added in the > same timeperiod). So it is nothing new even to your platform, I > suspect. I think the latent problem was always there, but almost every call to "test-tool genzeros" is gated on the EXPENSIVE prerequisite, and the remainder are quite small. This is the first one that is always run, and is bigger than the 256k buffer. (This test actually _is_ kind of slow, so one might argue it should be marked as EXPENSIVE, too, but obviously that is orthogonal). > diff --git c/t/helper/test-genzeros.c w/t/helper/test-genzeros.c > index 8ca988d621..9a1d3ee221 100644 > --- c/t/helper/test-genzeros.c > +++ w/t/helper/test-genzeros.c > @@ -17,12 +17,12 @@ 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) > + if (xwrite(1, zeros, ARRAY_SIZE(zeros)) < 0) > return -1; Sheesh. It even occurred to me with the big buffer that write limits could be the problem, but I thought to myself, "no, we have MAX_IO_SIZE" for that. The fact that this was write() and not xwrite() totally escaped my notice. :) So yeah, this seems like an obvious good fix. Using write_or_die() might be even better, as it would report errors rather than quietly returning non-zero. We could also move test-tool away from the left-hand side of the pipe in the test, which might have made this easier to diagnose. But not significantly so, and it makes the test even less efficient than it already is. -Peff
