* SIGSEGV when running git fetch @ 2025-11-28 22:56 Justin Su 2025-11-28 23:56 ` brian m. carlson 0 siblings, 1 reply; 6+ messages in thread From: Justin Su @ 2025-11-28 22:56 UTC (permalink / raw) To: git [-- Attachment #1: Type: text/plain, Size: 1821 bytes --] Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue. What did you do before the bug happened? `git fetch` What did you expect to happen? `git fetch` works normally What happened instead? ``` $ git fetch Fetching submodule catppuccin/bat Fetching submodule catppuccin/btop Fetching submodule catppuccin/micro Fetching submodule catppuccin/delta fatal: Unable to create '/home/ubuntu/.config/.git/objects/info/commit-graphs/commit-graph-chain.lock': File exists. Another git process seems to be running in this repository, e.g. an editor opened by 'git commit'. Please make sure all processes are terminated then try again. If it still fails, a git process may have crashed in this repository earlier: remove the file manually to continue. $ rm -f .git/objects/info/commit-graphs/commit-graph-chain.lock $ git fetch Fetching submodule catppuccin/bat Fetching submodule catppuccin/delta Fetching submodule catppuccin/btop Fetching submodule catppuccin/micro fish: Job 1, 'git fetch' terminated by signal SIGSEGV (Address boundary error) ``` What's different between what you expected and what actually happened? `git fetch` almost always results in a SIGSEGV, however the fetch appears to work Anything else you want to add: I am running Ubuntu 24.04.3 LTS on a c8g.metal-48xl AWS EC2 instance Please review the rest of the bug report below. You can delete any lines you don't wish to share. [System Info] git version: git version 2.43.0 cpu: aarch64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Linux 6.14.0-1017-aws #17~24.04.1-Ubuntu SMP Wed Nov 5 10:32:15 UTC 2025 aarch64 compiler info: gnuc: 13.3 libc info: glibc: 2.39 $SHELL (typically, interactive shell): /usr/bin/fish [Enabled Hooks] [-- Attachment #2: git-diagnostics-2025-11-28-2249.zip --] [-- Type: application/zip, Size: 28027 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SIGSEGV when running git fetch 2025-11-28 22:56 SIGSEGV when running git fetch Justin Su @ 2025-11-28 23:56 ` brian m. carlson 2025-11-29 0:08 ` Justin Su 0 siblings, 1 reply; 6+ messages in thread From: brian m. carlson @ 2025-11-28 23:56 UTC (permalink / raw) To: Justin Su; +Cc: git [-- Attachment #1: Type: text/plain, Size: 2799 bytes --] On 2025-11-28 at 22:56:19, Justin Su wrote: > Thank you for filling out a Git bug report! > Please answer the following questions to help us understand your issue. > > What did you do before the bug happened? `git fetch` > > What did you expect to happen? `git fetch` works normally > > What happened instead? > > ``` > $ git fetch > Fetching submodule catppuccin/bat > Fetching submodule catppuccin/btop > Fetching submodule catppuccin/micro > Fetching submodule catppuccin/delta > fatal: Unable to create > '/home/ubuntu/.config/.git/objects/info/commit-graphs/commit-graph-chain.lock': > File exists. > > Another git process seems to be running in this repository, e.g. > an editor opened by 'git commit'. Please make sure all processes > are terminated then try again. If it still fails, a git process > may have crashed in this repository earlier: > remove the file manually to continue. > > $ rm -f .git/objects/info/commit-graphs/commit-graph-chain.lock > > $ git fetch > Fetching submodule catppuccin/bat > Fetching submodule catppuccin/delta > Fetching submodule catppuccin/btop > Fetching submodule catppuccin/micro > fish: Job 1, 'git fetch' terminated by signal SIGSEGV (Address boundary error) > ``` > > What's different between what you expected and what actually happened? > `git fetch` almost always results in a SIGSEGV, however the fetch > appears to work I went ahead and looked at the repository you provided in the embedded archive and I think it's corrupt. First, you're missing the `.git/refs` directory, so my version of Git (2.51.0.338.gd7d06c2dae8) didn't even think it was a valid Git directory. I then ran `git fsck` and found a wide variety of missing blobs in your repository. When running `git fetch`, I did not get a segfault, but I did get this messsage: ---- % git fetch error: unable to load config blob object 'd38cf93d707c01ca18ed0233bcebb7aa172f0edd' fatal: You are attempting to fetch 06c0fdfd73559275c8d0423ddff0d3bcfd7e7f3f, which is in the commit graph file but not in the object database. This is probably due to repo corruption. If you are attempting to repair this repo corruption by refetching the missing object, use 'git fetch --refetch' with the missing object. ---- `git fetch --refetch` downloaded several objects, but I still have four missing blobs afterwards. So I would recommend running `git fsck` on your repository and see if it's corrupt and if you're missing objects. I agree that Git should not segfault, even with corruption, but I don't see it doing that (granted, on a Debian unstable amd64 system, not an Ubuntu arm64 system). We may have fixed the bug you're seeing in a newer version, though. -- brian m. carlson (they/them) Toronto, Ontario, CA [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 262 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SIGSEGV when running git fetch 2025-11-28 23:56 ` brian m. carlson @ 2025-11-29 0:08 ` Justin Su 2025-11-29 0:29 ` Justin Su 0 siblings, 1 reply; 6+ messages in thread From: Justin Su @ 2025-11-29 0:08 UTC (permalink / raw) To: brian m. carlson, Justin Su, git On Fri, Nov 28, 2025 at 6:56 PM brian m. carlson <sandals@crustytoothpaste•net> wrote: > > I went ahead and looked at the repository you provided in the embedded > archive and I think it's corrupt. First, you're missing the `.git/refs` > directory, so my version of Git (2.51.0.338.gd7d06c2dae8) didn't even > think it was a valid Git directory. The attachment was output by `git bugreport --diagnose=all`. According to the git-diagnose docs, it doesn't include `.git/refs` (which exists in my local repo). > I then ran `git fsck` and found a > wide variety of missing blobs in your repository. When I run `git fsck`, the output looks fine: ``` Checking object directories: 100% (256/256), done. Checking objects: 100% (679/679), done. Verifying commits in commit graph: 100% (132/132), done. ``` On Fri, Nov 28, 2025 at 6:56 PM brian m. carlson <sandals@crustytoothpaste•net> wrote: > > On 2025-11-28 at 22:56:19, Justin Su wrote: > > Thank you for filling out a Git bug report! > > Please answer the following questions to help us understand your issue. > > > > What did you do before the bug happened? `git fetch` > > > > What did you expect to happen? `git fetch` works normally > > > > What happened instead? > > > > ``` > > $ git fetch > > Fetching submodule catppuccin/bat > > Fetching submodule catppuccin/btop > > Fetching submodule catppuccin/micro > > Fetching submodule catppuccin/delta > > fatal: Unable to create > > '/home/ubuntu/.config/.git/objects/info/commit-graphs/commit-graph-chain.lock': > > File exists. > > > > Another git process seems to be running in this repository, e.g. > > an editor opened by 'git commit'. Please make sure all processes > > are terminated then try again. If it still fails, a git process > > may have crashed in this repository earlier: > > remove the file manually to continue. > > > > $ rm -f .git/objects/info/commit-graphs/commit-graph-chain.lock > > > > $ git fetch > > Fetching submodule catppuccin/bat > > Fetching submodule catppuccin/delta > > Fetching submodule catppuccin/btop > > Fetching submodule catppuccin/micro > > fish: Job 1, 'git fetch' terminated by signal SIGSEGV (Address boundary error) > > ``` > > > > What's different between what you expected and what actually happened? > > `git fetch` almost always results in a SIGSEGV, however the fetch > > appears to work > > I went ahead and looked at the repository you provided in the embedded > archive and I think it's corrupt. First, you're missing the `.git/refs` > directory, so my version of Git (2.51.0.338.gd7d06c2dae8) didn't even > think it was a valid Git directory. I then ran `git fsck` and found a > wide variety of missing blobs in your repository. > > When running `git fetch`, I did not get a segfault, but I did get this > messsage: > > ---- > % git fetch > error: unable to load config blob object 'd38cf93d707c01ca18ed0233bcebb7aa172f0edd' > fatal: You are attempting to fetch 06c0fdfd73559275c8d0423ddff0d3bcfd7e7f3f, which is in the commit graph file but not in the object database. > This is probably due to repo corruption. > If you are attempting to repair this repo corruption by refetching the missing object, use 'git fetch --refetch' with the missing object. > ---- > > `git fetch --refetch` downloaded several objects, but I still have four > missing blobs afterwards. > > So I would recommend running `git fsck` on your repository and see if > it's corrupt and if you're missing objects. I agree that Git should not > segfault, even with corruption, but I don't see it doing that (granted, > on a Debian unstable amd64 system, not an Ubuntu arm64 system). We may > have fixed the bug you're seeing in a newer version, though. > -- > brian m. carlson (they/them) > Toronto, Ontario, CA ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SIGSEGV when running git fetch 2025-11-29 0:08 ` Justin Su @ 2025-11-29 0:29 ` Justin Su 2025-11-29 0:49 ` Justin Su 0 siblings, 1 reply; 6+ messages in thread From: Justin Su @ 2025-11-29 0:29 UTC (permalink / raw) To: brian m. carlson, Justin Su, git I narrowed down my Git config to these 2 options that reproduce the crash: `git -c fetch.writeCommitGraph=true -c submodule.recurse=true fetch` I tested with a fresh clone of the repo on a new EC2 instance. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SIGSEGV when running git fetch 2025-11-29 0:29 ` Justin Su @ 2025-11-29 0:49 ` Justin Su 2025-11-29 11:16 ` Jeff King 0 siblings, 1 reply; 6+ messages in thread From: Justin Su @ 2025-11-29 0:49 UTC (permalink / raw) To: brian m. carlson, Justin Su, git After installing Git 2.52.0 from the Ubuntu PPA, I can no longer reproduce the crash. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SIGSEGV when running git fetch 2025-11-29 0:49 ` Justin Su @ 2025-11-29 11:16 ` Jeff King 0 siblings, 0 replies; 6+ messages in thread From: Jeff King @ 2025-11-29 11:16 UTC (permalink / raw) To: Justin Su; +Cc: brian m. carlson, git On Fri, Nov 28, 2025 at 07:49:26PM -0500, Justin Su wrote: > After installing Git 2.52.0 from the Ubuntu PPA, I can no longer > reproduce the crash. Seems likely this was the bug fixed by d70f554cdf (commit-graph: retain commit slab when closing NULL commit_graph, 2024-01-05). -Peff ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-11-29 11:16 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-11-28 22:56 SIGSEGV when running git fetch Justin Su 2025-11-28 23:56 ` brian m. carlson 2025-11-29 0:08 ` Justin Su 2025-11-29 0:29 ` Justin Su 2025-11-29 0:49 ` Justin Su 2025-11-29 11:16 ` Jeff King
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox