* bug report - BUG: builtin/pack-objects.c:4310: should_include_obj should only be called on existing objects @ 2025-04-25 18:14 Nik Garza 2025-04-25 18:30 ` Elijah Newren 0 siblings, 1 reply; 5+ messages in thread From: Nik Garza @ 2025-04-25 18:14 UTC (permalink / raw) To: git [-- Attachment #1.1: Type: text/plain, Size: 154 bytes --] reporting the attached bug: -- *Nikolas Garza* Software Engineer nikolas@applied•co (209) 499-1193 Applied Intuition, Inc. <https://applied.co/> [-- Attachment #1.2: Type: text/html, Size: 1774 bytes --] [-- Attachment #2: git-bugreport-2025-04-24-1725.txt --] [-- Type: text/plain, Size: 1905 bytes --] Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue. Continually hitting a oack-objects error when fetching tags in my repo. This occurs in CI during critical jobs. The issues is flaky but leads to an unreliable system. The Error: ERROR: Failed to fetch git tags from origin! Stdout: Stderr: BUG: builtin/pack-objects.c:4310: should_include_obj should only be called on existing objects error: pack-objects died of signal 6 fatal: could not finish pack-objects to repack local links fatal: index-pack failed What did you do before the bug happened? (Steps to reproduce your issue) ran the following: git fetch origin refs/tags/<version-identified>.*refs/tags/<version-identifier.* What did you expect to happen? (Expected behavior) tags to be fetched to the CI machine running this command What happened instead? (Actual behavior) error above was thrown causing the job to fail What's different between what you expected and what actually happened? pretty simple...we expect the fetch to work as expected Anything else you want to add: we are pretty sure retries will resovle the issue but that shouldn't bne necessary. we upgraded git from version 2.47.0 -> 2.49.0 and then started seeing the issue so we believe this is a low level git issue itself and not our use of git in our repo Please review the rest of the bug report below. You can delete any lines you don't wish to share. [System Info] git version: git version 2.49.0 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh libcurl: 8.5.0 zlib: 1.3 uname: Linux 5.15.0-134-generic #145~20.04.1-Ubuntu SMP Mon Feb 17 13:27:16 UTC 2025 x86_64 compiler info: gnuc: 13.3 libc info: glibc: 2.39 $SHELL (typically, interactive shell): <unset> [Enabled Hooks] post-checkout post-commit post-merge pre-commit pre-push ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: bug report - BUG: builtin/pack-objects.c:4310: should_include_obj should only be called on existing objects 2025-04-25 18:14 bug report - BUG: builtin/pack-objects.c:4310: should_include_obj should only be called on existing objects Nik Garza @ 2025-04-25 18:30 ` Elijah Newren 2025-04-28 19:23 ` Jonathan Tan 0 siblings, 1 reply; 5+ messages in thread From: Elijah Newren @ 2025-04-25 18:30 UTC (permalink / raw) To: Nik Garza; +Cc: git, Jonathan Tan On Fri, Apr 25, 2025 at 11:15 AM Nik Garza <nikolas@applied•co> wrote: > > reporting the attached bug: We prefer the bug be included inline rather than attached. However, from the reported error: ERROR: Failed to fetch git tags from origin! Stdout: Stderr: BUG: builtin/pack-objects.c:4310: should_include_obj should only be called on existing objects error: pack-objects died of signal 6 fatal: could not finish pack-objects to repack local links fatal: index-pack failed A couple quick checks shows: $ git grep "should_include_obj should only be called on existing objects" builtin/pack-objects.c: BUG("should_include_obj should only be called on existing objects"); $ git log --pretty=reference -S"should_include_obj should only be called on existing objects" builtin/pack-objects.c c08589efdc5 (index-pack: repack local links into promisor packs, 2024-11-01) which was a commit that was released as part of v2.48.0, and as you said, this started happening after you upgraded from 2.47 -> 2.49. Cc'ing the author of that commit for his comments. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: bug report - BUG: builtin/pack-objects.c:4310: should_include_obj should only be called on existing objects 2025-04-25 18:30 ` Elijah Newren @ 2025-04-28 19:23 ` Jonathan Tan 2025-04-28 22:55 ` Nik Garza 0 siblings, 1 reply; 5+ messages in thread From: Jonathan Tan @ 2025-04-28 19:23 UTC (permalink / raw) To: Elijah Newren; +Cc: Jonathan Tan, Nik Garza, git Elijah Newren <newren@gmail•com> writes: > Cc'ing the author of that commit for his comments. I took a look. I'm not sure why I made the assumption that should_include_obj() would only ever be called on objects in the repo - in process_tree() in list-objects.c, the case of a missing object is handled only after should_include_obj() is called. Looking back at the earliest mention of this on the list [1] I don't see any clues either. In any case, the fix is probably to change it so that should_include_obj() returns 0 if the object is absent. Having said that, I couldn't come up with a test that exercises this failure mode. Nik, do you have a minimal repo that reproduces this error? If yes, if you could contribute a test in the form of the 'after fetching descendants of non-promisor commits, gc works' test in t5616, that would help prevent regressions in the future. [1] https://lore.kernel.org/git/fb2c202591b466eea33b4585e47b70e9086603bb.1729549127.git.jonathantanmy@google.com/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: bug report - BUG: builtin/pack-objects.c:4310: should_include_obj should only be called on existing objects 2025-04-28 19:23 ` Jonathan Tan @ 2025-04-28 22:55 ` Nik Garza 2025-10-17 15:57 ` Sam Estep 0 siblings, 1 reply; 5+ messages in thread From: Nik Garza @ 2025-04-28 22:55 UTC (permalink / raw) To: Jonathan Tan Cc: Elijah Newren, git, Jamison Lahman, Jack Zhang, Michael Diamond Resending.... I haven't been able to define a repro case unfortunately. The error surfaces randomly in our CI infrastructure. I'll take a look at some of the failures we have seen and try to come up with a repro. Will add a test if I can find something. On Mon, Apr 28, 2025 at 12:23 PM Jonathan Tan <jonathantanmy@google•com> wrote: > > Elijah Newren <newren@gmail•com> writes: > > Cc'ing the author of that commit for his comments. > > I took a look. I'm not sure why I made the assumption that > should_include_obj() would only ever be called on objects in the repo > - in process_tree() in list-objects.c, the case of a missing object is > handled only after should_include_obj() is called. Looking back at the > earliest mention of this on the list [1] I don't see any clues either. > > In any case, the fix is probably to change it so that > should_include_obj() returns 0 if the object is absent. > > Having said that, I couldn't come up with a test that exercises this > failure mode. Nik, do you have a minimal repo that reproduces this > error? If yes, if you could contribute a test in the form of the 'after > fetching descendants of non-promisor commits, gc works' test in t5616, > that would help prevent regressions in the future. > > [1] https://lore.kernel.org/git/fb2c202591b466eea33b4585e47b70e9086603bb.1729549127.git.jonathantanmy@google.com/ -- Nikolas Garza Software Engineer nikolas@applied•co (209) 499-1193 Applied Intuition, Inc. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: bug report - BUG: builtin/pack-objects.c:4310: should_include_obj should only be called on existing objects 2025-04-28 22:55 ` Nik Garza @ 2025-10-17 15:57 ` Sam Estep 0 siblings, 0 replies; 5+ messages in thread From: Sam Estep @ 2025-10-17 15:57 UTC (permalink / raw) To: jonathantanmy; +Cc: nikolas, diamond, git, jack, jl, newren I hit this same bug today: https://github.com/samestep/npc/issues/6 I'm using Git v2.51.0. As Nik mentioned, the issue is flaky, but I have been able to reproduce it several times today on both x86_64-linux and aarch64-darwin via these steps: $ git clone --mirror --filter=tree:0 https://github.com/NixOS/nixpkgs.git Cloning into bare repository 'nixpkgs.git'... remote: Enumerating objects: 1403208, done. remote: Counting objects: 100% (1204/1204), done. remote: Compressing objects: 100% (1164/1164), done. remote: Total 1403208 (delta 70), reused 273 (delta 40), pack-reused 1402004 (from 2) Receiving objects: 100% (1403208/1403208), 550.95 MiB | 19.74 MiB/s, done. Resolving deltas: 100% (71770/71770), done. Enumerating objects: 1, done. Counting objects: 100% (1/1), done. Writing objects: 100% (1/1), done. Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0) $ cd nixpkgs.git $ git fetch --no-show-forced-updates From https://github.com/NixOS/nixpkgs - [deleted] (none) -> gh-readonly-queue/master/pr-452910-91484645881d96272b133ad577cbb314c3af446f - [deleted] (none) -> gh-readonly-queue/master/pr-452916-93e25250a9459a0d62e9156f06d9ab66fa081ebd - [deleted] (none) -> gh-readonly-queue/master/pr-452934-9347aa5ba848ac348dd123e5c6b28a5e69ebebee - [deleted] (none) -> refs/pull/435349/merge - [deleted] (none) -> refs/pull/452910/merge - [deleted] (none) -> refs/pull/452916/merge - [deleted] (none) -> refs/pull/452934/merge remote: Enumerating objects: 228, done. remote: Counting objects: 100% (228/228), done. remote: Compressing objects: 100% (223/223), done. remote: Total 228 (delta 5), reused 152 (delta 5), pack-reused 0 (from 0) Receiving objects: 100% (228/228), 123.31 KiB | 17.62 MiB/s, done. Resolving deltas: 100% (5/5), done. BUG: builtin/pack-objects.c:4835: should_include_obj should only be called on existing objects error: pack-objects died of signal 6 fatal: could not finish pack-objects to repack local links fatal: index-pack failed If the error doesn't occur immediately, it should eventually occur if you keep re-running that last command: $ git fetch --no-show-forced-updates In case it's relevant, my Git version is built from Nixpkgs commit 82c2e0d6dde50b17ae366d2aa36f224dc19af469, and I have this in my global Git config: [fetch] all = true prune = true On Mon, Apr 28, 2025 at 12:23 PM Jonathan Tan <jonathantanmy@google•com> wrote: > In any case, the fix is probably to change it so that > should_include_obj() returns 0 if the object is absent. Does this still seem like the right approach? ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-10-17 15:57 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-04-25 18:14 bug report - BUG: builtin/pack-objects.c:4310: should_include_obj should only be called on existing objects Nik Garza 2025-04-25 18:30 ` Elijah Newren 2025-04-28 19:23 ` Jonathan Tan 2025-04-28 22:55 ` Nik Garza 2025-10-17 15:57 ` Sam Estep
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox