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

From: Dmitriy Panteleyev <dpantel@gmail.com>
Date: Dec 1, 2024, 22:24 UTC
Message-ID: <CAJ-DG_A3RY0ngY-pc6riho=OyzX2VjeaR2LRGb5=ru3CNruECA@mail.gmail.com>
In-Reply-To: <20241201213636.GB145938@coredump.intra.peff.net>

On Sun, Dec 1, 2024 at 2:36 PM Jeff King <peff@peff.net> wrote:

Show 22 quoted lines

>
> On Sun, Dec 01, 2024 at 10:17:44AM -0700, Dmitriy Panteleyev wrote:
>
> > > > 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 <peff@peff.net>
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 <peff@peff.net>
    Signed-off-by: Taylor Blau <me@ttaylorr.com>

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

Show 5 quoted lines

> 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