From: Justin Su Date: Sat, 29 Nov 2025 00:08:41 GMT Subject: Re: SIGSEGV when running git fetch Message-ID: In-Reply-To: On Fri, Nov 28, 2025 at 6:56 PM brian m. carlson 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 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