On Fri, Nov 13, 2020 at 11:23:28PM +0100, SZEDER Gábor wrote: > This patch breaks the test 'truncated bitmap fails gracefully (ewah)' > when run with GIT_TEST_DEFAULT_HASH=sha256: Thanks for reporting. It's mostly unluckiness that is unrelated to this commit. We're corrupting the bitmap by truncating it: > test_copy_bytes 256 <$bitmap >$bitmap.tmp && > mv -f $bitmap.tmp $bitmap && and then expecting to notice the problem. But it really depends on which bitmaps we try to look at, and exactly where the truncation is. And this commit just happens to rearrange the exact bytes we write to the bitmap file. If I do this: diff --git a/t/t5310-pack-bitmaps.sh b/t/t5310-pack-bitmaps.sh index 68badd63cb..a83e7a93fb 100755 --- a/t/t5310-pack-bitmaps.sh +++ b/t/t5310-pack-bitmaps.sh @@ -436,7 +436,7 @@ test_expect_success 'truncated bitmap fails gracefully (ewah)' ' git rev-list --use-bitmap-index --count --all >expect && bitmap=$(ls .git/objects/pack/*.bitmap) && test_when_finished "rm -f $bitmap" && - test_copy_bytes 256 <$bitmap >$bitmap.tmp && + test_copy_bytes 270 <$bitmap >$bitmap.tmp && mv -f $bitmap.tmp $bitmap && git rev-list --use-bitmap-index --count --all >actual 2>stderr && test_cmp expect actual && then it passes with both sha1 and sha256. But what's slightly disturbing is this output: > --- expect 2020-11-13 22:20:39.246355100 +0000 > +++ actual 2020-11-13 22:20:39.254355294 +0000 > @@ -1 +1 @@ > -239 > +236 > error: last command exited with $?=1 We're actually producing the wrong answer here, which implies that ewah_read_mmap() is not being careful enough. Or possibly we are feeding it extra bytes (e.g., letting it run over into the name-hash cache or into the trailer checksum). I think we'll have to dig further into this, probably running the sha256 case in a debugger to see what offsets we actually end up reading. -Peff
