On Sun, Dec 01, 2024 at 03:24:35PM -0700, Dmitriy Panteleyev wrote:
> You are right, Jeff, I needed to run one more bisect. But it does point to
> the commit I linked above. The bisect result is:
Thanks for checking. I'm still puzzled how this commit:
> 04fb96219abc0cbe46ba084997dc9066de3ac889 is the first bad commit
> commit 04fb96219abc0cbe46ba084997dc9066de3ac889
> Author: Jeff King <peff@xxxxxxxx>
> Date: Thu Nov 17 17:37:58 2022 -0500
>
> parse_object(): drop extra "has" check before checking object type
>
> When parsing an object of unknown type, we check to see if it's a blob,
> so we can use our streaming code path. This uses oid_object_info() to
> check the type, but before doing so we call repo_has_object_file(). This
> latter is pointless, as oid_object_info() will already fail if the
> object is missing. Checking it ahead of time just complicates the code
> and is a waste of resources (albeit small).
>
> Let's drop the redundant check.
could be the culprit, though. The diff is just
diff --git a/object.c b/object.c
index 8a74eb85e9..16eb944e98 100644
--- a/object.c
+++ b/object.c
@@ -287,8 +287,7 @@ struct object *parse_object_with_flags(struct repository *r,
}
if ((obj && obj->type == OBJ_BLOB && repo_has_object_file(r, oid)) ||
- (!obj && repo_has_object_file(r, oid) &&
- oid_object_info(r, oid, NULL) == OBJ_BLOB)) {
+ (!obj && oid_object_info(r, oid, NULL) == OBJ_BLOB)) {
if (!skip_hash && stream_object_signature(r, repl) < 0) {
error(_("hash mismatch %s"), oid_to_hex(oid));
return NULL;
So it is actually doing _less_, though what it is removing is going to
just be a pack .idx lookup (or maybe a stat() call if the object is
loose).
> I am not at all familiar with the standard process for this, but the way I ran
> the test is:
>
> (0. cloned test project into /nfs/proj/ and made a change)
> 1. cloned git repo (from github) into /tmp/git/
> 2. ran bisect in /tmp/git/, starting with v2.34.1 (good) and v2.43.1 (bad)
> 3. ran `make all` in /tmp/git/
> 4. in /nfs/proj/ ran `/tmp/git/bin-wrappers/git commit -m 'test'`
> 5. repeated 2-4
That sounds reasonable. I'm still not sure what's going on. It's always
possible that commit introduced a problem, but I just don't see it. So I
still have a suspicion (especially given that your symptom is a bus
error) that the problem might not be deterministic.
I wonder if building git with:
make SANITIZE=address,undefined
and running the same test might yield anything useful.
-Peff
