Thread (12 messages) 12 messages, 2 authors, 2024-12-05

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

From: Dmitriy Panteleyev <hidden>
Date: 2024-12-03 02:48:18

On Mon, Dec 2, 2024 at 1:41 PM Jeff King [off-list ref] wrote:
quoted hunk ↗ jump to hunk
On Sun, Dec 01, 2024 at 03:24:35PM -0700, Dmitriy Panteleyev wrote:
quoted
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:
quoted
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.
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).
quoted
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
Not sure if this is useful, but this is what I got:

AddressSanitizer:DEADLYSIGNAL
=================================================================
==155141==ERROR: AddressSanitizer: BUS on unknown address (pc
0x78811e863aed bp 0x7ffe9d5ac800 sp 0x7ffe9d5ac770 T0)
==155141==The signal is caused by a READ memory access.
==155141==Hint: this fault was caused by a dereference of a high value
address (see register values below).  Disassemble the provided pc to
learn which register was used.
    #0 0x78811e863aed in inflate
(/lib/x86_64-linux-gnu/libz.so.1+0xfaed) (BuildId:
bbefe2bbdc367b0c3cfbfcf80c579930496fb963)
    #1 0x563e32ec7e5f in git_inflate /tmp/git_tests/git/zlib.c:118
    #2 0x563e32bde431 in unpack_loose_header
/tmp/git_tests/git/object-file.c:1271
    #3 0x563e32be429c in loose_object_info /tmp/git_tests/git/object-file.c:1474
    #4 0x563e32be5348 in do_oid_object_info_extended
/tmp/git_tests/git/object-file.c:1582
    #5 0x563e32be5dac in oid_object_info_extended
/tmp/git_tests/git/object-file.c:1640
    #6 0x563e32be5dac in oid_object_info /tmp/git_tests/git/object-file.c:1656
    #7 0x563e32bf8b57 in parse_object_with_flags /tmp/git_tests/git/object.c:290
    #8 0x563e32cfbd19 in write_ref_to_lockfile refs/files-backend.c:1772
    #9 0x563e32d0196e in lock_ref_for_update refs/files-backend.c:2582
    #10 0x563e32d0196e in files_transaction_prepare refs/files-backend.c:2755
    #11 0x563e32ce6800 in ref_transaction_prepare /tmp/git_tests/git/refs.c:2266
    #12 0x563e32ce6a5a in ref_transaction_commit /tmp/git_tests/git/refs.c:2315
    #13 0x563e32d8c44e in update_head_with_reflog
/tmp/git_tests/git/sequencer.c:1197
    #14 0x563e326b2f51 in cmd_commit builtin/commit.c:1834
    #15 0x563e3263002a in run_builtin /tmp/git_tests/git/git.c:466
    #16 0x563e3263002a in handle_builtin /tmp/git_tests/git/git.c:721
    #17 0x563e32633ff8 in run_argv /tmp/git_tests/git/git.c:788
    #18 0x563e32633ff8 in cmd_main /tmp/git_tests/git/git.c:926
    #19 0x563e3262c6a4 in main /tmp/git_tests/git/common-main.c:57
    #20 0x78811d42a1c9 in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
    #21 0x78811d42a28a in __libc_start_main_impl ../csu/libc-start.c:360
    #22 0x563e3262f6d4 in _start (/tmp/git_tests/git/git+0xa726d4)
(BuildId: 197ee6cc3c63db9e10cfed4585ab78b52790454a)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: BUS
(/lib/x86_64-linux-gnu/libz.so.1+0xfaed) (BuildId:
bbefe2bbdc367b0c3cfbfcf80c579930496fb963) in inflate
==155141==ABORTING
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help