Re: [BUG] commit fails with 'bus error' when working directory is on an NFS share

On Sun, Dec 1, 2024 at 2:36 PM Jeff King [off-list ref] wrote:

On Sun, Dec 01, 2024 at 10:17:44AM -0700, Dmitriy Panteleyev wrote:

quoted

quoted

quoted

I attempted to upgrade git to v2.47.1, with the same result.

I then downgraded git to v2.34.1 (the version for the previous
distribution release) and the error has resolved.

Can you try bisecting between v2.34.1 and v2.43.0 to see which commit
introduces the problem for you?

-Peff

Bisecting: 0 revisions left to test after this (roughly 0 steps)
[04fb96219abc0cbe46ba084997dc9066de3ac889] parse_object(): drop extra
"has" check before checking object type

That seems like an unlikely commit to introduce the problem you're
seeing. And how did we end up with 0 revisions left to check, but no
final outcome? Did you need to do one more test and "git bisect
good/bad" on this commit?

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:

04fb96219abc0cbe46ba084997dc9066de3ac889 is the first bad commit
commit 04fb96219abc0cbe46ba084997dc9066de3ac889
Author: Jeff King [off-list ref]
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.

    Signed-off-by: Jeff King [off-list ref]
    Signed-off-by: Taylor Blau [off-list ref]

 object.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

Or alternatively, can you share what you're doing to test the bisection?
That might help us reproduce. I kind of wonder if the results might not
be deterministic, to end up at an apparently unrelated commit like that.

-Peff

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