git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 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;
as well as URLs for NNTP newsgroup(s).