Created attachment 1652757 [details]
File: backtrace

Created attachment 1652758 [details]
File: core_backtrace

Created attachment 1652759 [details]
File: cpuinfo

Created attachment 1652760 [details]
File: dso_list

Created attachment 1652761 [details]
File: environ

Created attachment 1652762 [details]
File: exploitable

Created attachment 1652763 [details]
File: limits

Created attachment 1652764 [details]
File: maps

Created attachment 1652765 [details]
File: mountinfo

Created attachment 1652766 [details]
File: open_fds

Created attachment 1652767 [details]
File: proc_pid_status

Similar problem has been detected:

Working with vscode and git extensions.

reporter:       libreport-2.12.0
backtrace_rating: 4
cgroup:         0::/user.slice/user-5040.slice/user/gnome-launched-code.desktop-11511.scope
cmdline:        /usr/bin/git -c core.quotepath=false -c color.ui=false -c log.showSignature=false log --format=%x3c%x2ff%x3e%n%x3cr%x3e%x20%H%n%x3ca%x3e%x20%aN%n%x3ce%x3e%x20%aE%n%x3cd%x3e%x20%at%n%x3cc%x3e%x20%ct%n%x3cp%x3e%x20%P%n%x3cs%x3e%n%B%n%x3c%x2fs%x3e%n%x3cf%x3e -n10 --follow -L 38,38:cnv_deployment.md -- cnv_deployment.md
crash_function: try_to_follow_renames
executable:     /usr/bin/git
journald_cursor: s=4e16243fd4134b439fc0244544f19978;i=af47f;b=dd63b26b592545f1aa7ee5fe0189a6d5;m=820b6bdb;t=59edebbe6d4d2;x=b5f8a6b87d408886
kernel:         5.4.19-200.fc31.x86_64
package:        git-core-2.24.1-1.fc31
reason:         git killed by SIGSEGV
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            5040

There are two commits that introduced changes between 2.24. and 2.23. in functions related to this bug.

https://git.kernel.org/pub/scm/git/git.git/commit/?id=a2bb801f6a430f6049e5c9729a8f3bf9097d9b34

This is the main commit^


https://git.kernel.org/pub/scm/git/git.git/commit/?id=eef5204190e6b99c9d3694fc416bd031cf253490

And this is the helper function^

In functions diff_tree_oid() and try_to_follow_renames() there are no arguments check.

Right now I'm trying to reproduce this bug with debug build flags. Is there some specific work flow
that might have caused this bug to appear?

*** Bug 1806440 has been marked as a duplicate of this bug. ***

Similar problem has been detected:

Using GitKraken.

reporter:       libreport-2.12.0
backtrace_rating: 4
cmdline:        /usr/bin/git -c core.quotepath=false -c color.ui=false -c log.showSignature=false log --format=%x3cr%x3e%x20%H -n2 --follow -L 10,10:secure.yml -- secure.yml
crash_function: try_to_follow_renames
executable:     /usr/bin/git
journald_cursor: s=392c657ed43540e5968de9f4af0cc93b;i=7717e6;b=ceba1e872ea54f30ab482ff73879f09f;m=9701c8c7;t=59f9f3abb7465;x=38e21b37f1cd260b
kernel:         5.5.5-200.fc31.x86_64
package:        git-core-2.24.1-1.fc31
reason:         git killed by SIGSEGV
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            1000

(In reply to Ondřej Pohořelský from comment #13)
> There are two commits that introduced changes between 2.24. and 2.23. in
> functions related to this bug.
> 
> https://git.kernel.org/pub/scm/git/git.git/commit/
> ?id=a2bb801f6a430f6049e5c9729a8f3bf9097d9b34
> 
> This is the main commit^
> 
> 
> https://git.kernel.org/pub/scm/git/git.git/commit/
> ?id=eef5204190e6b99c9d3694fc416bd031cf253490
> 
> And this is the helper function^
> 
> In functions diff_tree_oid() and try_to_follow_renames() there are no
> arguments check.
> 
> Right now I'm trying to reproduce this bug with debug build flags. Is there
> some specific work flow
> that might have caused this bug to appear?

I'm sorry but I cannot describe a specific workflow to reproduce it.
I was running VS Code with the GitLens extension which calls git all the time behind the scenes, e.g. to show the last commit on every line of a file.
Suddenly the problem reporter popped up with this exception so it appeared completely random to me.

Since then I was trying to reproduce this bug with debug build flags and I still wasn't able to reproduce it.
I wrote an e-mail to upstream regarding this issue.[0] 


[0]https://lore.kernel.org/git/CA+B51BFFvn9puia8+kheeWkDfOQ7RYHTcGa74M5aeiTd8-QJXA@mail.gmail.com/

*** Bug 1813438 has been marked as a duplicate of this bug. ***

*** Bug 1823028 has been marked as a duplicate of this bug. ***

*** Bug 1833686 has been marked as a duplicate of this bug. ***

*** Bug 1787072 has been marked as a duplicate of this bug. ***

Just to update folks watching this bug but not the git list thread...

While there's not yet a patch yet, a reproduction recipe was reported by Alexandr Miloslavskiy¹:

> The problem is easy to reproduce with this (replace 1.c with any file):
>    git log --follow -L 1,1:1.c -- 1.c

This prompted a reply from SZEDER Gábor about combining --follow and -L²:

> Don't do this.  In particular:
> 
>   - Don't use line-level log with a pathspec, because the
>     documentation of 'git log -L' explicitly told you not to do so
>     ("You may not give any pathspec limiters.").  This should have
>     errored out since the beginning, but, unfortunately, has never
>     been enforced.
> 
>   - Don't use '-L' with '--follow'.  On one hand, line-level log on
>     its own already follows file renames, even multiple files at once,
>     there is no need for an additional '--follow' (which can only
>     follow one file).  OTOH, you shouldn't be able to use '-L' and
>     '--follow' together, because the former forbids a pathspec, while
>     the latter requires one.
> 
> In any case, '--follow' has always been an ugly hack on top of the
> revision walking machinery, while line-level log is a rather poorly
> integrated bolt-on.  They simply weren't designed to work together, as
> evidenced by their contradicting requirements about the pathspec.

Obviously, we want to patch git to not unceremoniously die.  The likely fix will be to error out if those options are combined.

All the reports we seem to have come from vscode calling git with these options.  It may be worthwhile for any vscode users affected by this to report it to the vscode project and point them to the git list thread.  That would let them get a head start on dropping the combined usage of --follow and -L for the reasons noted above.

¹ https://lore.kernel.org/git/3c722d21-ee57-7d20-81fb-0399f02f1bc7@syntevo.com/
² https://lore.kernel.org/git/20200310165723.GB3122@szeder.dev/

*** Bug 1835117 has been marked as a duplicate of this bug. ***

*** Bug 1835565 has been marked as a duplicate of this bug. ***

*** Bug 1841100 has been marked as a duplicate of this bug. ***

Similar problem has been detected:

I was not actively using git when the error got reported, however, VS Code was open and I use Git Lens plugin on VS Code

reporter:       libreport-2.13.1
backtrace_rating: 4
cgroup:         0::/user.slice/user-1000.slice/user/gnome-launched-code.desktop-3450.scope
cmdline:        /usr/bin/git -c core.quotepath=false -c color.ui=false -c log.showSignature=false log --format=%x3cr%x3e%x20%H -n2 --follow -L 67,67:products.py -- products.py
crash_function: try_to_follow_renames
executable:     /usr/bin/git
journald_cursor: s=09c491940bd645f185b837e4c29cd5bd;i=ba46;b=2790f2177051441493ebd0b8df503729;m=fd221fc4;t=5b072a2f72491;x=1803806f5da04cfc
kernel:         5.8.10-200.fc32.x86_64
package:        git-core-2.26.2-1.fc32
reason:         git killed by SIGSEGV
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            1000

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

For folks hitting this issue, it looks like the Git Lens plugin for VS code has been updated to no longer trigger the git log segfault¹.

And, I believe the underlying segfault in git log when the incompatible --follow and -L options are used is also fixed in upstream git².  I'll try to verify that sometime soon and get it into the Fedora package(s).

¹ https://github.com/eamodio/vscode-gitlens/issues/1139
² https://lore.kernel.org/git/xmqqy2jglv29.fsf_-_@gitster.c.googlers.com/ and/or
  https://github.com/git/git/commit/39664cb0aca42f240468ddf84fe75df4172ab63f

*** Bug 1893772 has been marked as a duplicate of this bug. ***

FEDORA-2020-5476485ad2 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-5476485ad2

FEDORA-2020-5476485ad2 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-5476485ad2`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-5476485ad2

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-5476485ad2 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.