Re: Bugreport: pack-objects died of signal 11

[Emily Noneman <emily.noneman@gmail.com>]

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
>
>