# bug report - BUG: builtin/pack-objects.c:4310: should_include_obj should only be called on existing objects

5 messages from 2025-04-25 to 2025-10-17. Participants: Nik Garza, Elijah Newren, Jonathan Tan, Sam Estep.
Thread: https://gitlist.dev/t/63352

## Nik Garza, 2025-04-25 18:14

Subject: bug report - BUG: builtin/pack-objects.c:4310: should_include_obj should only be called on existing objects
Message-ID: <CA+ODqj2s68nPWzd1KHH3vUm3SiFHuf2b=+hmNuWesi-bo3c8_g@mail.gmail.com>
URL: https://gitlist.dev/e/CA%2BODqj2s68nPWzd1KHH3vUm3SiFHuf2b%3D%2BhmNuWesi-bo3c8_g%40mail.gmail.com

```
reporting the attached bug:



-- 

*Nikolas Garza*

Software Engineer

nikolas@applied.co

(209) 499-1193

Applied Intuition, Inc. <https://applied.co/>


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

```

## Elijah Newren, 2025-04-25 18:30

Subject: Re: bug report - BUG: builtin/pack-objects.c:4310: should_include_obj should only be called on existing objects
Message-ID: <CABPp-BFiLURYmELQ1omyPJ+49cVxk1h4rPYj42zMwGUW-NUUGQ@mail.gmail.com>
URL: https://gitlist.dev/e/CABPp-BFiLURYmELQ1omyPJ%2B49cVxk1h4rPYj42zMwGUW-NUUGQ%40mail.gmail.com
In-Reply-To: <CA+ODqj2s68nPWzd1KHH3vUm3SiFHuf2b=+hmNuWesi-bo3c8_g@mail.gmail.com>

```
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.

```

## Jonathan Tan, 2025-04-28 19:23

Subject: Re: bug report - BUG: builtin/pack-objects.c:4310: should_include_obj should only be called on existing objects
Message-ID: <20250428192320.3595509-1-jonathantanmy@google.com>
URL: https://gitlist.dev/e/20250428192320.3595509-1-jonathantanmy%40google.com
In-Reply-To: <CABPp-BFiLURYmELQ1omyPJ+49cVxk1h4rPYj42zMwGUW-NUUGQ@mail.gmail.com>

```
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/

```

## Nik Garza, 2025-04-28 22:55

Subject: Re: bug report - BUG: builtin/pack-objects.c:4310: should_include_obj should only be called on existing objects
Message-ID: <CA+ODqj34b2DsvjxGgVb=jSaTUNYRh_nNtaCzCx8QiJ8QFsRecA@mail.gmail.com>
URL: https://gitlist.dev/e/CA%2BODqj34b2DsvjxGgVb%3DjSaTUNYRh_nNtaCzCx8QiJ8QFsRecA%40mail.gmail.com
In-Reply-To: <20250428192320.3595509-1-jonathantanmy@google.com>

```
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.

```

## Sam Estep, 2025-10-17 15:57

Subject: Re: bug report - BUG: builtin/pack-objects.c:4310: should_include_obj should only be called on existing objects
Message-ID: <20251017155754.1425091-1-sam@samestep.com>
URL: https://gitlist.dev/e/20251017155754.1425091-1-sam%40samestep.com
In-Reply-To: <CA+ODqj34b2DsvjxGgVb=jSaTUNYRh_nNtaCzCx8QiJ8QFsRecA@mail.gmail.com>

```
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?

```