Description of problem: Just running VS Code with the GitLens extension while suddenly this happened in the background. Version-Release number of selected component: git-core-2.24.1-1.fc31 Additional info: reporter: libreport-2.11.3 backtrace_rating: 4 cgroup: 0::/user.slice/user-1000.slice/user/gnome-launched-code.desktop-6492.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 121,121:tests/Sag.Ticketing.Api.UnitTests/Controllers/ReservationsControllerTestFixture.cs -- tests/Sag.Ticketing.Api.UnitTests/Controllers/ReservationsControllerTestFixture.cs crash_function: try_to_follow_renames executable: /usr/bin/git journald_cursor: s=f313f0b9f2754b4f822aa9004ffc9691;i=9f0c4;b=6ee678652c6641bf868f5cf49ff4a130;m=503d19011;t=59c4221dab368;x=aa121bf6f36f2d9d kernel: 5.4.8-200.fc31.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 try_to_follow_renames at tree-diff.c:613 #1 diff_tree_oid at tree-diff.c:709 #2 queue_diffs at line-log.c:858 #3 process_ranges_ordinary_commit at line-log.c:1160 #4 process_ranges_arbitrary_commit at line-log.c:1237 #5 line_log_filter at line-log.c:1273 #6 prepare_revision_walk at revision.c:3373 #7 cmd_log_walk at builtin/log.c:386 #8 cmd_log at builtin/log.c:733 #9 run_builtin at git.c:444
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.