Re: Bugreport: pack-objects died of signal 11

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

I have an updated backtrace with optimizations turned off:
Thread 2 received signal SIGSEGV, Segmentation fault.
0x000000010016f770 in git_config_check_init (repo=0x0) at config.c:2538
2538 if (repo->config && repo->config->hash_initialized)
(gdb) bt
#0  0x000000010016f770 in git_config_check_init (repo=0x0) at config.c:2538
#1  0x000000010016f94d in repo_config_get_string (repo=0x0,
key=0x10036e541 "status.showuntrackedfiles", dest=0x7ff7bfefc6d0) at
config.c:2574
#2  0x00000001001b4dbf in new_untracked_cache_flags
(istate=0x7ff7bfefc858) at dir.c:2781
#3  0x00000001001b0027 in new_untracked_cache (istate=0x7ff7bfefc858,
flags=-1) at dir.c:2797
#4  0x00000001001aff6c in add_untracked_cache (istate=0x7ff7bfefc858)
at dir.c:2806
#5  0x0000000100276126 in tweak_untracked_cache
(istate=0x7ff7bfefc858) at read-cache.c:1996
#6  0x000000010027352e in post_read_index_from (istate=0x7ff7bfefc858)
at read-cache.c:2028
#7  0x0000000100273228 in read_index_from (istate=0x7ff7bfefc858,
path=0x600002c0ac00
"/Users/emily.noneman/workspace/webdev/.NetLedger_LocalBranchData.git/index",
    gitdir=0x600002c04080
"/Users/emily.noneman/workspace/webdev/.NetLedger_LocalBranchData.git")
at read-cache.c:2457
#8  0x00000001002a98c1 in add_index_objects_to_pending
(revs=0x7ff7bfefcfe8, flags=0) at revision.c:1783
#9  0x00000001002adb4b in handle_revision_pseudo_opt
(revs=0x7ff7bfefcfe8, argv=0x600003704020, flags=0x7ff7bfefcaf8) at
revision.c:2717
#10 0x00000001002acd2c in setup_revisions (argc=6,
argv=0x600003704000, revs=0x7ff7bfefcfe8, opt=0x7ff7bfefcb78) at
revision.c:2806
#11 0x00000001000a747e in get_object_list (revs=0x7ff7bfefcfe8, ac=6,
av=0x600003704000) at builtin/pack-objects.c:3993
#12 0x00000001000a5f30 in cmd_pack_objects (argc=0,
argv=0x7ff7bfeff968, prefix=0x0) at builtin/pack-objects.c:4472
#13 0x0000000100002a03 in run_builtin (p=0x1003d0fb8 <commands+1992>,
argc=11, argv=0x7ff7bfeff968) at git.c:466
#14 0x0000000100001528 in handle_builtin (argc=11,
argv=0x7ff7bfeff968) at git.c:720
#15 0x0000000100002406 in run_argv (argcp=0x7ff7bfeff7dc,
argv=0x7ff7bfeff7d0) at git.c:787
#16 0x00000001000012f9 in cmd_main (argc=11, argv=0x7ff7bfeff968) at git.c:920
#17 0x00000001001155c6 in main (argc=12, argv=0x7ff7bfeff960) at
common-main.c:56

Ævar Arnfjörð Bjarmason, your patch fixed the issue for me! Thank you!


On Thu, Aug 4, 2022 at 5:18 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>
>
> On Thu, Aug 04 2022, Derrick Stolee wrote:
>
> > On 8/4/2022 2:21 PM, Emily Noneman wrote:
> >> 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
> >
> > Here is where things are confusing:
> >
> > * tweak_untracked_cache() takes an 'istate' that is non-NULL here.
> >
> > * The next spot in the stack is new_untracked_cache() with a NULL 'istate'.
> >
> > The only way these are connected is by a missing stack frame (probably
> > optimized out) calling add_untracked_cache(). Still, it should be
> > passing 'istate' throughout this process.
> >
> > The repo_config_get_string() call must also be coming from
> > new_untracked_cache_flags() which is again a missing stack frame,
> > but is called from new_untracked_cache(). Strangely, it's using
> > a NULL 'repo' here which should have come from 'istate->repo', so
> > we should have had a segfault earlier.
> >
> > Sorry for the drive-by commentary without any solution. This is
> > just genuinely puzzling to me.
>
> I think this segfault might be fixed by this patch of mine, which I
> wrote for something unrelated back in April (but it was never sent to
> the list).
>
>         https://github.com/avar/git/commit/d83bfa866ba
>
> Emily and/or Paul: Are you able to test the patch to see if it would
> work, diff here: https://github.com/avar/git/commit/d83bfa866ba.patch
>
> It's exactly on the codepath in this stacktrace,
> i.e. add_index_objects_to_pending() in revision.c will do before/after:
>
>         - struct index_state istate = { NULL };
>         + struct index_state istate = { .repo = revs->repo };
>
> Then when we're all the way down in new_untracked_cache_flags() we do:
>
>         struct repository *repo = istate->repo;
>
> Which then calls (indirectly) git_config_check_init(), and we segfault
> not because istate is NULL, but because the "repo" it's carrying is
> NULL.
>
> But maybe I'm wrong, I haven't been able to reproduce this.
>
> The reason I wrote that patch (as can be seen if you peek at the WIP
> branch it's at) is because I ran into a similar dependency between
> the_index and the_repo & an istate variable being passed around with
> fsmonitor-settings.c.