Re: [BUG] Segfault in "git submodule"
I instructed downstream to update their repository. On Mon, Oct 1, 2018 at 2:31 PM Raymond Jennings wrote: > > 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 wrote: > > > > On Sat, Sep 29, 2018 at 9:43 AM Raymond Jennings 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 wrote: > > > > > > > > On Sat, Sep 29, 2018 at 5:31 PM Ævar Arnfjörð Bjarmason > > > > 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
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 wrote: > > On Sat, Sep 29, 2018 at 9:43 AM Raymond Jennings 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 wrote: > > > > > > On Sat, Sep 29, 2018 at 5:31 PM Ævar Arnfjörð Bjarmason > > > 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
Re: [BUG] Segfault in "git submodule"
On Sat, Sep 29, 2018 at 9:43 AM Raymond Jennings 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 wrote: > > > > On Sat, Sep 29, 2018 at 5:31 PM Ævar Arnfjörð Bjarmason > > 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
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 wrote: > > On Sat, Sep 29, 2018 at 5:31 PM Ævar Arnfjörð Bjarmason > 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
Re: [BUG] Segfault in "git submodule"
On Sat, Sep 29, 2018 at 5:31 PM Ævar Arnfjörð Bjarmason 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
Re: [BUG] Segfault in "git submodule"
On Sat, Sep 29 2018, Raymond Jennings wrote: > [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=, referent=, > oid=, refname=, ref_store= 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=, referent=, > oid=, refname=, ref_store= 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 0x55e862fcad5c in refs_read_ref_full (flags=0x7ffdc834b1bc, > oid=0x7ffdc834b1c0, resolve_flags=1, refname=0x55e863062253 "HEAD", > refs=) at refs.c:224 > #3 refs_head_ref (refs=, fn=fn@entry=0x55e862f25fb0 > , cb_data=cb_data@entry=0x7ffdc834b300) at > refs.c:1314 > #4 0x55e862f292a2 in status_submodule (flags=0, prefix= 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=, fn= out>, list=) at builtin/submodule--helper.c:404 > #7 module_status (argc=, argv=, > prefix=) at builtin/submodule--helper.c:698 > #8 0x55e862eaec95 in run_builtin (argv=, > argc=, p=) at git.c:346 > #9 handle_builtin (argc=, argv=) at git.c:554 > #10 0x55e862eaf985 in run_argv (argv=0x7ffdc834be20, > argcp=0x7ffdc834be2c) at git.c:606 > #11 cmd_main (argc=, argv=) at git.c:683 > #12 0x55e862eae96a 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.
