Re: Segfault in git when using git logs
- From
SZEDER Gábor <szeder.dev@gmail.com>
- Date
- Nov 3, 2020, 10:15 UTC
- Message-ID
- <20201103101553.GH24813@szeder.dev>
- In-Reply-To
- <20201102144321.GA3962443@coredump.intra.peff.net>
On Mon, Nov 02, 2020 at 09:43:21AM -0500, Jeff King wrote:
Show 11 quoted lines
> On Mon, Nov 02, 2020 at 03:59:59PM +0200, Sathyajith Bhat wrote: > > > Simple repro steps > > > > mkdir git_segfault_test && cd git_segfault_test && echo > > "Hello" > hello.log > > git init && git add hello.log && git commit -m "init commit" > > > > Now, use git log to show commit logs using command > > > > git log --follow -L 1,1:hello.log -- hello.log
While Git should never segfault, no matter what, this is a bogus git invocation to begin with: the second sentence in the description of 'git log -L' clearly states that "You may not give any pathspec limiters", so this command should have errored out from early days, but, unfortunately, it was never enforced. This also means that '-L' and '--follow' are incompatible, because while the former forbids any pathspecs, the latter requires exactly one; and line-level log does its own rename following anyway.
VS Code should be fixed to call 'git log -L 1,1:hello.log' instead, without '--follow' and without pathspec.
Show 27 quoted lines
> > What did you expect to happen? (Expected behavior)
> > Git should not segfault
>
> Thanks for making this reproduction recipe! I can easily see the problem
> on my system. Looks like the segfault was introduced by a2bb801f6a
> (line-log: avoid unnecessary full tree diffs, 2019-08-21). I've cc'd the
> author.
>
> That commit causes the line-log to clear the set of pathspecs, but the
> --follow option requires exactly one pathspec (and it even makes sure
> the user gives us one, but that happens before we clear it internally).
> Something like this makes the segfault go away:
>
> diff --git a/line-log.c b/line-log.c
> index 42c5e41f68..f789863928 100644
> --- a/line-log.c
> +++ b/line-log.c
> @@ -847,6 +847,7 @@ static void queue_diffs(struct line_log_data *range,
> clear_pathspec(&opt->pathspec);
> parse_pathspec_from_ranges(&opt->pathspec, range);
> }
> + opt->flags.follow_renames = 0;
> DIFF_QUEUE_CLEAR(&diff_queued_diff);
> diff_tree_oid(parent_tree_oid, tree_oid, "", opt);
> if (opt->detect_rename && diff_might_be_rename()) {
>
> but I'm not clear on how "--follow" and "-L" are supposed to interact.They shouldn't, I would say. Though it would be great if their rename-following logic would be unified. In particular, line-level log does a better job at rename following in some ways, notably it can track multiple files at once, while '--follow' can only handle a single file. So I think the rename following logic should be extracted from 'line-log.c' and made more generic, and it should be used to implement '--follow', removing some restrictions of the latter, not to mention removing the duplicated logic.
(This might be a good GSoC project, though some of Linus' remarks in 750f7b668f (Finally implement "git log --follow", 2007-06-19) like "you did have to know and understand the internal git diff generation machinery pretty well, and had to really be able to follow how commit generation interacts with generating patches and generating the log" and "this patch does seem to be firmly in the core "Linus or Junio" territory" are worrying...)
Show 5 quoted lines
> I > wouldn't expect --follow to do anything at all with line-log (nor for it > to be useful to specify pathspecs outside of the -L option). So possibly > this is restoring the behavior prior to that commit, or possibly it's > just papering over a breakage. ;)
Perhaps, though arguably the original breakage was that 'git log -L...:file -- file' was meant to error out, but it didn't.