I am seeing a similar issue with git on macos. git repack fails with
signal 11. Other git commands seem to be working fine. My version info:
[System Info]
git version:
git version 2.37.1.311.g350dc9f0e8
cpu: x86_64
built from commit: 350dc9f0e8974b6fcbdeb3808186c5a79c3e7386
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 21.5.0 Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:22
PDT 2022; root:xnu-8020.121.3~4/RELEASE_X86_64 x86_64
compiler info: clang: 13.1.6 (clang-1316.0.21.2.5)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh
[Enabled Hooks]
The stack trace:
Thread 2 received signal SIGSEGV, Segmentation fault.
git_config_check_init (repo=0x0) at config.c:2538
2538 if (repo->config && repo->config->hash_initialized)
(gdb) bt
#0 git_config_check_init (repo=0x0) at config.c:2538
#1 0x00000001001197a8 in repo_config_get_string (repo=0x0,
key=0x1002a3c49 "status.showuntrackedfiles", dest=0x0,
dest@entry=0x7ff7bfefc1f0) at config.c:2574
#2 0x000000010014a85b in new_untracked_cache_flags (istate=0x0) at
dir.c:2781
#3 new_untracked_cache (istate=0x0, flags=-1) at dir.c:2797
#4 0x00000001001d68f1 in tweak_untracked_cache (istate=0x7ff7bfefc7e0)
at read-cache.c:1996
#5 post_read_index_from (istate=0x7ff7bfefc7e0,
istate@entry=0x600003b02920) at read-cache.c:2028
#6 0x00000001001d6599 in read_index_from (istate=0x600003b02920,
istate@entry=0x0, path=path@entry=0xffffffff <error: Cannot access
memory at address 0xffffffff>,
gitdir=0x600002c08080
"/Users/emily.noneman/workspace/webdev/.NetLedger_LocalBranchData.git")
at read-cache.c:2457
#7 0x00000001001fcb2d in add_index_objects_to_pending
(revs=0x600003b02920, revs@entry=0x7ff7bfefe9a0, flags=flags@entry=0) at
revision.c:1783
#8 0x00000001002001e4 in handle_revision_pseudo_opt
(revs=0x7ff7bfefe9a0, argv=0x600003700020, flags=<optimized out>) at
revision.c:2717
#9 setup_revisions (argc=61876512, argv=0x600003700000, revs=<optimized
out>, revs@entry=0x1002a3c49, opt=<optimized out>,
opt@entry=0x7ff7bfefca50) at revision.c:2806
#10 0x0000000100084092 in get_object_list (revs=0x1002a3c49,
revs@entry=0x0, ac=0, av=0x1002a3c49) at builtin/pack-objects.c:3993
#11 0x0000000100080a07 in cmd_pack_objects (argc=<optimized out>,
argv=<optimized out>, prefix=<optimized out>) at builtin/pack-objects.c:4466
#12 0x0000000100005313 in run_builtin (p=0x600003b02920,
p@entry=0xffffffff, argc=11, argc@entry=0, argv=<optimized out>,
argv@entry=0x1002a3c49) at git.c:466
#13 0x0000000100004566 in handle_builtin (argc=0, argv=0x1002a3c49) at
git.c:720
#14 0x0000000100003b59 in run_argv (argcp=0x7ff7bfeff7a4,
argv=0x7ff7bfeff798) at git.c:787
#15 cmd_main (argc=11, argc@entry=0, argv=0x7ff7bfeff968,
argv@entry=0x1002a3c49) at git.c:920
#16 0x00000001000d49a5 in main (argc=0, argv=0x1002a3c49) at
common-main.c:56
On 7/14/22 5:37 PM, Jeff King wrote:
On Tue, Jul 12, 2022 at 10:51:29AM +0200, Paul Horn wrote:
ultimately, `git repack` segfaults:
$ git repack
error: pack-objects died of signal 11
Can you provide a backtrace that shows where we segfaulted? If you can
build Git from source and have access to a debugger like gdb, that
should be enough.
One option is to make sure core dumps are enabled (probably "ulimit -c
unlimited"), then run the failing repack, then find the core file
(usually in the current directory, but I'm not sure offhand about
macOS), and then open the debugger on it ("gdb /path/to/your/git
/path/to/core").
But perhaps easier may be to directly run the buggy pack-objects
invocation. I pulled the options here from your trace file. Something
like:
gdb -ex 'set args pack-objects \
--delta-base-offset tmp-pack \
--keep-true-parents --honor-pack-keep --non-empty \
--all --reflog --indexed-objects --unpacked --incremental \
</dev/null' \
/path/to/your/git
Then "r" to run inside the debugger, which will stop if we segfault. And
then "bt" will show the backtrace.
Alternatively, is it possible to make the offending repository available
(even off-list)?
-Peff
