threads / bug / 49457

[BUG] Segfault in "git submodule"

Subject: [BUG] Segfault in "git submodule"

## tl;dr

7 messages between Sep 29, 2018 and Oct 2, 2018.

replies: 6people: 4as markdown or json

Raymond Jennings· Sep 29, 2018, 15:22 UTC · lore

[New LWP 19644] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `git submodule--helper status'. Program terminated with signal SIGSEGV, Segmentation fault. #0 refs_read_raw_ref (type=<optimized out>, referent=<optimized out>, oid=<optimized out>, refname=<optimized out>, ref_store=<optimized out>) at refs.c:1451 1451 return ref_store->be->read_raw_ref(ref_store, refname, oid, referent, type); #0 refs_read_raw_ref (type=<optimized out>, referent=<optimized out>, oid=<optimized out>, refname=<optimized out>, ref_store=<optimized out>) at refs.c:1451 #1 refs_resolve_ref_unsafe (refs=0x0, refname=refname@entry=0x55e863062253 "HEAD", resolve_flags=resolve_flags@entry=1, oid=oid@entry=0x7ffdc834b1c0, flags=flags@entry=0x7ffdc834b1bc) at refs.c:1493 #2 0x000055e862fcad5c in refs_read_ref_full (flags=0x7ffdc834b1bc, oid=0x7ffdc834b1c0, resolve_flags=1, refname=0x55e863062253 "HEAD", refs=<optimized out>) at refs.c:224 #3 refs_head_ref (refs=<optimized out>, fn=fn@entry=0x55e862f25fb0 <handle_submodule_head_ref>, cb_data=cb_data@entry=0x7ffdc834b300) at refs.c:1314 #4 0x000055e862f292a2 in status_submodule (flags=0, prefix=<optimized out>, ce_flags=0, ce_oid=0x55e86468d4d4, path=0x55e86468d4e8 "lpc-doc") at builtin/submodule--helper.c:624 #5 status_submodule_cb (cb_data=0x7ffdc834b240, list_item=0x55e86468d490) at builtin/submodule--helper.c:665 #6 for_each_listed_submodule (cb_data=<optimized out>, fn=<optimized out>, list=<optimized out>) at builtin/submodule--helper.c:404 #7 module_status (argc=<optimized out>, argv=<optimized out>, prefix=<optimized out>) at builtin/submodule--helper.c:698 #8 0x000055e862eaec95 in run_builtin (argv=<optimized out>, argc=<optimized out>, p=<optimized out>) at git.c:346 #9 handle_builtin (argc=<optimized out>, argv=<optimized out>) at git.c:554 #10 0x000055e862eaf985 in run_argv (argv=0x7ffdc834be20, argcp=0x7ffdc834be2c) at git.c:606 #11 cmd_main (argc=<optimized out>, argv=<optimized out>) at git.c:683 #12 0x000055e862eae96a in main (argc=3, argv=0x7ffdc834c078) at common-main.c:43

Ævar Arnfjörð Bjarmason· Sep 29, 2018, 15:29 UTC · re: Raymond Jennings · lore

Re: [BUG] Segfault in "git submodule"

On Sat, Sep 29 2018, Raymond Jennings wrote:
Show 39 quoted lines
> [New LWP 19644]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Core was generated by `git submodule--helper status'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  refs_read_raw_ref (type=<optimized out>, referent=<optimized out>,
> oid=<optimized out>, refname=<optimized out>, ref_store=<optimized
> out>) at refs.c:1451
> 1451 return ref_store->be->read_raw_ref(ref_store, refname, oid,
> referent, type);
> #0  refs_read_raw_ref (type=<optimized out>, referent=<optimized out>,
> oid=<optimized out>, refname=<optimized out>, ref_store=<optimized
> out>) at refs.c:1451
> #1  refs_resolve_ref_unsafe (refs=0x0,
> refname=refname@entry=0x55e863062253 "HEAD",
> resolve_flags=resolve_flags@entry=1, oid=oid@entry=0x7ffdc834b1c0,
> flags=flags@entry=0x7ffdc834b1bc) at refs.c:1493
> #2  0x000055e862fcad5c in refs_read_ref_full (flags=0x7ffdc834b1bc,
> oid=0x7ffdc834b1c0, resolve_flags=1, refname=0x55e863062253 "HEAD",
> refs=<optimized out>) at refs.c:224
> #3  refs_head_ref (refs=<optimized out>, fn=fn@entry=0x55e862f25fb0
> <handle_submodule_head_ref>, cb_data=cb_data@entry=0x7ffdc834b300) at
> refs.c:1314
> #4  0x000055e862f292a2 in status_submodule (flags=0, prefix=<optimized
> out>, ce_flags=0, ce_oid=0x55e86468d4d4, path=0x55e86468d4e8
> "lpc-doc") at builtin/submodule--helper.c:624
> #5  status_submodule_cb (cb_data=0x7ffdc834b240,
> list_item=0x55e86468d490) at builtin/submodule--helper.c:665
> #6  for_each_listed_submodule (cb_data=<optimized out>, fn=<optimized
> out>, list=<optimized out>) at builtin/submodule--helper.c:404
> #7  module_status (argc=<optimized out>, argv=<optimized out>,
> prefix=<optimized out>) at builtin/submodule--helper.c:698
> #8  0x000055e862eaec95 in run_builtin (argv=<optimized out>,
> argc=<optimized out>, p=<optimized out>) at git.c:346
> #9  handle_builtin (argc=<optimized out>, argv=<optimized out>) at git.c:554
> #10 0x000055e862eaf985 in run_argv (argv=0x7ffdc834be20,
> argcp=0x7ffdc834be2c) at git.c:606
> #11 cmd_main (argc=<optimized out>, argv=<optimized out>) at git.c:683
> #12 0x000055e862eae96a in main (argc=3, argv=0x7ffdc834c078) at common-main.c:43

Can you consistently reproduce this? Maybe Stefan can make some sense of this, but it would be really useful if you could compile git from the master branch with CFLAGS="-O0 -g" and run gdb with that and paste that backtrace, and even better if you're in a position to share a copy of the repository where this happens.

Duy Nguyen· Sep 29, 2018, 15:33 UTC · re: Ævar Arnfjörð Bjarmason · lore

Re: [BUG] Segfault in "git submodule"

On Sat, Sep 29, 2018 at 5:31 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

> > #1  refs_resolve_ref_unsafe (refs=0x0,
> > refname=refname@entry=0x55e863062253 "HEAD",
> > resolve_flags=resolve_flags@entry=1, oid=oid@entry=0x7ffdc834b1c0,
> > flags=flags@entry=0x7ffdc834b1bc) at refs.c:1493

refs is NULL. It looks like somebody fails to get the right submodule ref store (or tries to get it but fails to check if it may return NULL)

-- 
Duy
Raymond Jennings· Sep 29, 2018, 16:43 UTC · re: Duy Nguyen · lore

Re: [BUG] Segfault in "git submodule"

I have a repo, but it appears to be specific to staging area state. It only segfaults when I have a certain file deleted.

Where do you want me to upload it? On Sat, Sep 29, 2018 at 8:34 AM Duy Nguyen <pclouds@gmail.com> wrote:

Show 13 quoted lines
>
> On Sat, Sep 29, 2018 at 5:31 PM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
> > > #1  refs_resolve_ref_unsafe (refs=0x0,
> > > refname=refname@entry=0x55e863062253 "HEAD",
> > > resolve_flags=resolve_flags@entry=1, oid=oid@entry=0x7ffdc834b1c0,
> > > flags=flags@entry=0x7ffdc834b1bc) at refs.c:1493
>
> refs is NULL. It looks like somebody fails to get the right submodule
> ref store (or tries to get it but fails to check if it may return
> NULL)
> --
> Duy
Stefan Beller· Oct 1, 2018, 19:19 UTC · re: Raymond Jennings · lore

Re: [BUG] Segfault in "git submodule"

On Sat, Sep 29, 2018 at 9:43 AM Raymond Jennings <shentino@gmail.com> wrote:
Show 17 quoted lines
>
> I have a repo, but it appears to be specific to staging area state.
> It only segfaults when I have a certain file deleted.
>
> Where do you want me to upload it?
> On Sat, Sep 29, 2018 at 8:34 AM Duy Nguyen <pclouds@gmail.com> wrote:
> >
> > On Sat, Sep 29, 2018 at 5:31 PM Ævar Arnfjörð Bjarmason
> > <avarab@gmail.com> wrote:
> > > > #1  refs_resolve_ref_unsafe (refs=0x0,
> > > > refname=refname@entry=0x55e863062253 "HEAD",
> > > > resolve_flags=resolve_flags@entry=1, oid=oid@entry=0x7ffdc834b1c0,
> > > > flags=flags@entry=0x7ffdc834b1bc) at refs.c:1493
> >
> > refs is NULL. It looks like somebody fails to get the right submodule
> > ref store (or tries to get it but fails to check if it may return
> > NULL)
This is spot on.

Raymond, are you on Git v2.16.0 by any chance? (and if now which version are you on).

I suspect 2.16, as that is a version of Git, in which there happens to be a call into the refs subsystem in submodule--helper.c in line 624.

Is it possible to upgrade Git (to v2.18.0 or later) or cherry-pick 74b6bda32f (submodule: check for NULL return of get_submodule_ref_store(), 2018-03-28) into your copy of Git?

Thanks, Stefan

Raymond Jennings· Oct 1, 2018, 21:31 UTC · re: Stefan Beller · lore

Re: [BUG] Segfault in "git submodule"

Yes, git 2.16.4 to be exact.

I upgraded to 2.19 after ~arch keywording the package on gentoo and that fixed it. On Mon, Oct 1, 2018 at 12:19 PM Stefan Beller <sbeller@google.com> wrote:

Show 34 quoted lines
>
> On Sat, Sep 29, 2018 at 9:43 AM Raymond Jennings <shentino@gmail.com> wrote:
> >
> > I have a repo, but it appears to be specific to staging area state.
> > It only segfaults when I have a certain file deleted.
> >
> > Where do you want me to upload it?
> > On Sat, Sep 29, 2018 at 8:34 AM Duy Nguyen <pclouds@gmail.com> wrote:
> > >
> > > On Sat, Sep 29, 2018 at 5:31 PM Ævar Arnfjörð Bjarmason
> > > <avarab@gmail.com> wrote:
> > > > > #1  refs_resolve_ref_unsafe (refs=0x0,
> > > > > refname=refname@entry=0x55e863062253 "HEAD",
> > > > > resolve_flags=resolve_flags@entry=1, oid=oid@entry=0x7ffdc834b1c0,
> > > > > flags=flags@entry=0x7ffdc834b1bc) at refs.c:1493
> > >
> > > refs is NULL. It looks like somebody fails to get the right submodule
> > > ref store (or tries to get it but fails to check if it may return
> > > NULL)
>
> This is spot on.
>
> Raymond, are you on Git v2.16.0 by any chance?
> (and if now which version are you on).
>
> I suspect 2.16, as that is a version of Git, in which there happens to be
> a call into the refs subsystem in submodule--helper.c in line 624.
>
> Is it possible to upgrade Git (to v2.18.0 or later) or cherry-pick
> 74b6bda32f (submodule: check for NULL return of get_submodule_ref_store(),
> 2018-03-28) into your copy of Git?
>
> Thanks,
> Stefan
Raymond Jennings· Oct 2, 2018, 04:10 UTC · re: Raymond Jennings · lore

Re: [BUG] Segfault in "git submodule"

I instructed downstream to update their repository. On Mon, Oct 1, 2018 at 2:31 PM Raymond Jennings <shentino@gmail.com> wrote:

Show 40 quoted lines
>
> Yes, git 2.16.4 to be exact.
>
> I upgraded to 2.19 after ~arch keywording the package on gentoo and
> that fixed it.
> On Mon, Oct 1, 2018 at 12:19 PM Stefan Beller <sbeller@google.com> wrote:
> >
> > On Sat, Sep 29, 2018 at 9:43 AM Raymond Jennings <shentino@gmail.com> wrote:
> > >
> > > I have a repo, but it appears to be specific to staging area state.
> > > It only segfaults when I have a certain file deleted.
> > >
> > > Where do you want me to upload it?
> > > On Sat, Sep 29, 2018 at 8:34 AM Duy Nguyen <pclouds@gmail.com> wrote:
> > > >
> > > > On Sat, Sep 29, 2018 at 5:31 PM Ævar Arnfjörð Bjarmason
> > > > <avarab@gmail.com> wrote:
> > > > > > #1  refs_resolve_ref_unsafe (refs=0x0,
> > > > > > refname=refname@entry=0x55e863062253 "HEAD",
> > > > > > resolve_flags=resolve_flags@entry=1, oid=oid@entry=0x7ffdc834b1c0,
> > > > > > flags=flags@entry=0x7ffdc834b1bc) at refs.c:1493
> > > >
> > > > refs is NULL. It looks like somebody fails to get the right submodule
> > > > ref store (or tries to get it but fails to check if it may return
> > > > NULL)
> >
> > This is spot on.
> >
> > Raymond, are you on Git v2.16.0 by any chance?
> > (and if now which version are you on).
> >
> > I suspect 2.16, as that is a version of Git, in which there happens to be
> > a call into the refs subsystem in submodule--helper.c in line 624.
> >
> > Is it possible to upgrade Git (to v2.18.0 or later) or cherry-pick
> > 74b6bda32f (submodule: check for NULL return of get_submodule_ref_store(),
> > 2018-03-28) into your copy of Git?
> >
> > Thanks,
> > Stefan

← back to recent threads