* 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