Hi folks,
Running the test suit with GIT_TEST_FAIL_PREREQS=1 on master (and
next) seem to result in some failures:
Test Summary Report
-------------------
t5300-pack-object.sh (Wstat: 256 Tests: 46 Failed: 2)
Failed tests: 35-36
Non-zero exit status: 1
t7810-grep.sh (Wstat: 256 Tests: 229 Failed: 1)
Failed test: 160
Non-zero exit status: 1
Files=924, Tests=22400, 422 wallclock secs (12.57 usr 2.52 sys +
601.02 cusr 1047.02 csys = 1663.13 CPU)
Result: FAIL
A quick git-bisect run seems to point back to this commit:
3b1ca60f8f317b483c8c1805ab500ff2b014cbec is the first bad commit
commit 3b1ca60f8f317b483c8c1805ab500ff2b014cbec
Author: Taylor Blau <me@xxxxxxxxxxxx>
Date: Tue Dec 8 17:03:14 2020 -0500
ewah/ewah_bitmap.c: avoid open-coding ALLOC_GROW()
'ewah/ewah_bitmap.c:buffer_grow()' is responsible for growing the buffer
used to store the bits of an EWAH bitmap. It is essentially doing the
same task as the 'ALLOC_GROW()' macro, so use that instead.
This simplifies the callers of 'buffer_grow()', who no longer have to
ask for a specific size, but rather specify how much of the buffer they
need. They also no longer need to guard 'buffer_grow()' behind an if
statement, since 'ALLOC_GROW()' (and, by extension, 'buffer_grow()') is
a noop if the buffer is already large enough.
But, the most significant change is that this fixes a bug when calling
buffer_grow() with both 'alloc_size' and 'new_size' set to 1. In this
case, truncating integer math will leave the new size set to 1, causing
the buffer to never grow.
Instead, let alloc_nr() handle this, which asks for '(new_size + 16) * 3
/ 2' instead of 'new_size * 3 / 2'.
Signed-off-by: Taylor Blau <me@xxxxxxxxxxxx>
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
ewah/ewah_bitmap.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
I also found that a test is failing with protocol V1 set
(GIT_TEST_PROTOCOL_VERSION=1)
Test Summary Report
-------------------
t5606-clone-options.sh (Wstat: 256 Tests: 15 Failed: 1)
Failed test: 14
Non-zero exit status: 1
Files=924, Tests=22852, 568 wallclock secs (12.69 usr 2.73 sys +
842.87 cusr 1322.91 csys = 2181.20 CPU)
Result: FAIL
Which git-bisect is telling me that was caused by the same commit.
Regards,
Son Luong.
