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"
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
[BUG] Segfault in "git submodule"
[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=) 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=) 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=, 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=, 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
Re: Bug in default commit hook (improperly forbidding a single blank line at EOF)
On 09/07/15 21:55, Jeff King wrote: On Mon, Sep 07, 2015 at 06:37:29PM -0700, Raymond Jennings wrote: Please see https://bugs.gentoo.org/show_bug.cgi?id=559920 for further details. Files *should* have a single blank line at the end, because a line should always have a newline at the end. I'm not sure I follow. Lines should have a newline at the end, but there is no need to start a _new_ blank line. So a file with zero bytes has no lines (and no newline). A file that contains a single line, like "one\n", has each line end in a newline, and the file ends in a newline. There is no blank line. A file like "one\n\n" has two lines: one with text, and a blank line at the end. Can you clarify (preferably by showing a byte sequence of the file in question) what file you are feeding to the hook, what output you get, and what output you expect? Adding a newline to the end of a file whose last line doesn't have one should be legal...as long as you don't create empty lines at the end. If you mean turning "foo" (a file with no newline!) into "foo\n", I agree that is legal, and does not create an empty blank line at the end. But I don't think the hook complains about that. Sorry, my mistake. I just took a look at the file on console with mcedit, and it looks like gedit lied to me. I'll be contacting gedit's maintainers with this instead, sorry for the spam. E.g., we can create a sequence of file content: git init echo -n one >file git add file git commit -m 'no newline' echo >>file git add file git commit -m 'complete line' echo >>file git add file git commit -m 'add a blank line' and run "log --check", which runs the same code that the pre-commit hook does: git log --check Git complains only about the final, which looks right to me. If you want to redefine git's idea of which whitespace is worth complaining about, try: git config core.whitespace -blank-at-eof See the description of core.whitespace in "git help config" for the complete list. You can also set it per-file using gitattributes. See "git help attributes", section "Checking whitespace errors". -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug in default commit hook (improperly forbidding a single blank line at EOF)
Please see https://bugs.gentoo.org/show_bug.cgi?id=559920 for further details. Files *should* have a single blank line at the end, because a line should always have a newline at the end. Adding a newline to the end of a file whose last line doesn't have one should be legal...as long as you don't create empty lines at the end. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
