summaryrefslogtreecommitdiffstats
path: root/t/t4013/diff.format-patch_--attach_--stdout_initial..main^
diff options
context:
space:
mode:
authorPatrick Steinhardt <ps@pks.im>2026-02-23 17:00:09 +0100
committerJunio C Hamano <gitster@pobox.com>2026-02-23 13:19:00 -0800
commit13eb65d36615d7269df053015bddf7987ef6d923 (patch)
tree65f33f90aadf14798d90e0bf7cf1088b90a635e5 /t/t4013/diff.format-patch_--attach_--stdout_initial..main^
parent41b42e3527eb6b0ab4b557d16adedcd255c9045f (diff)
downloadgit-13eb65d36615d7269df053015bddf7987ef6d923.tar.gz
git-13eb65d36615d7269df053015bddf7987ef6d923.zip
pack-check: fix verification of large objects
It was reported [1] that git-fsck(1) may sometimes run into an infinite loop when processing packfiles. This bug was bisected to c31bad4f7d (packfile: track packs via the MRU list exclusively, 2025-10-30), which refactored our lsit of packfiles to only be tracked via an MRU list, exclusively. This isn't entirely surprising: any caller that iterates through the list of packfiles and then hits `find_pack_entry()`, for example because they read an object from it, may cause the MRU list to be updated. And if the caller is unlucky, this may cause the mentioned infinite loop. While this mechanism is somewhat fragile, it is still surprising that we encounter it when verifying the packfile. We iterate through objects in a given pack one by one and then read them via their offset, and doing this shouldn't ever end up in `find_pack_entry()`. But there is an edge case here: when the object in question is a blob bigger than "core.largeFileThreshold", then we will be careful to not read it into memory. Instead, we read it via an object stream by calling `odb_read_object_stream()`, and that function will perform an object lookup via `odb_read_object_info()`. So in the case where there are at least two blobs in two different packfiles, and both of these blobs exceed "core.largeFileThreshold", then we'll run into an infinite loop because we'll always update the MRU. We could fix this by improving `repo_for_each_pack()` to not update the MRU, and this would address the issue. But the fun part is that using `odb_read_object_stream()` is the wrong thing to do in the first place: it may open _any_ instance of this object, so we ultimately cannot be sure that we even verified the object in our given packfile. Fix this bug by creating the object stream for the packed object directly via `packfile_read_object_stream()`. Add a test that would have caused the infinite loop. [1]: <20260222183710.2963424-1-sandals@crustytoothpaste.net> Reported-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t4013/diff.format-patch_--attach_--stdout_initial..main^')
0 files changed, 0 insertions, 0 deletions