summaryrefslogtreecommitdiff
path: root/t/t5572-pull-submodule.sh
diff options
context:
space:
mode:
authorLibravatar Ævar Arnfjörð Bjarmason <avarab@gmail.com>2021-11-11 06:18:55 +0100
committerLibravatar Junio C Hamano <gitster@pobox.com>2021-11-11 10:41:54 -0800
commit168a937bbcf74370267fe04f5368035948745baa (patch)
tree6c558744b02d9a6d0ab1e10aaee842ba0feea45a /t/t5572-pull-submodule.sh
parentfsck: report invalid object type-path combinations (diff)
downloadtgif-168a937bbcf74370267fe04f5368035948745baa.tar.xz
object-file: fix SEGV on free() regression in v2.34.0-rc2
Fix a regression introduced in my 96e41f58fe1 (fsck: report invalid object type-path combinations, 2021-10-01). When fsck-ing blobs larger than core.bigFileThreshold, we'd free() a pointer to uninitialized memory. This issue would have been caught by SANITIZE=address, but since it involves core.bigFileThreshold, none of the existing tests in our test suite covered it. Running them with the "big_file_threshold" in "environment.c" changed to say "6" would have shown this failure, but let's add a dedicated test for this scenario based on Han Xin's report[1]. The bug was introduced between v9 and v10[2] of the fsck series merged in 061a21d36d8 (Merge branch 'ab/fsck-unexpected-type', 2021-10-25). 1. https://lore.kernel.org/git/20211111030302.75694-1-hanxin.hx@alibaba-inc.com/ 2. https://lore.kernel.org/git/cover-v10-00.17-00000000000-20211001T091051Z-avarab@gmail.com/ Reported-by: Han Xin <chiyutianyi@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t5572-pull-submodule.sh')
0 files changed, 0 insertions, 0 deletions