Push to repository results in "PANIC: runtime error: invalid memory address or nil pointer dereference" #13139

New Issue

GiteaMirror · 2025-11-02T10:32:24-06:00

GiteaMirror commented

2025-11-02 10:32:24 -06:00

Originally created by @gmaxwell447 on GitHub (Jun 12, 2024).

Description

We have been porting repositories from a legacy Gitlab instance, and have had no issues except for one particular repository. This repo could not be directly migrated by Gitea; the raw Gitlab repos (*.git) were dropped into the appropriate owner directory on Gitea and successfully adopted by Gitea using the documented process. Everything looks great and the repo can be successfully cloned over HTTP or SSH.

However, any sort of push operation (commit, branch delete) results in a panic from an "invalid memory address or nil pointer dereference." The gist includes three different panic origins and their stack traces.

The repo in particular has a few large binary blobs, 17 branches, 630 commits, 235 tags, and occupies 58 MiB. I will note that the ".pack" file under objects/pack occupies 79553430 bytes. We're willing to prune out old commits and branches, but would have to do that off Gitea since push is currently broken, if that is our only option.

I would attempt to reproduce it on the Gitea demo site but the repo contains proprietary IP.

Thank you!

Gitea Version

1.22.0+41-g3fcf865a4b

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

https://gist.github.com/gmaxwell447/b45ee124ad25e04bdc39619a254d6247

Screenshots

No response

Git Version

2.39.3

Operating System

Rocky Release 9.3 with SELinux enabled, Red Hat Server Level 1 Security Profile

How are you running Gitea?

I have tried the downloaded 1.22.0 binary (gitea_1.22.0_dev-1092-g02d4a62e3) along with the nightly build (1.22.0+41-g3fcf865a4b). Gitea is running on a Hyper-V hosted VM (no container), launched as a systemd service (service file included in gist).

Database

MySQL/MariaDB

Originally created by @gmaxwell447 on GitHub (Jun 12, 2024). ### Description We have been porting repositories from a legacy Gitlab instance, and have had no issues except for one particular repository. This repo could not be directly migrated by Gitea; the raw Gitlab repos (*.git) were dropped into the appropriate owner directory on Gitea and successfully adopted by Gitea using the [documented process](https://docs.gitea.com/help/faq#how-to-adopt-repositories-from-disk). Everything looks great and the repo can be successfully cloned over HTTP or SSH. However, any sort of push operation (commit, branch delete) results in a panic from an "invalid memory address or nil pointer dereference." The gist includes three different panic origins and their stack traces. The repo in particular has a few large binary blobs, 17 branches, 630 commits, 235 tags, and occupies 58 MiB. I will note that the ".pack" file under objects/pack occupies 79553430 bytes. We're willing to prune out old commits and branches, but would have to do that off Gitea since push is currently broken, if that is our only option. I would attempt to reproduce it on the Gitea demo site but the repo contains proprietary IP. Thank you! ### Gitea Version 1.22.0+41-g3fcf865a4b ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist https://gist.github.com/gmaxwell447/b45ee124ad25e04bdc39619a254d6247 ### Screenshots _No response_ ### Git Version 2.39.3 ### Operating System Rocky Release 9.3 with SELinux enabled, Red Hat Server Level 1 Security Profile ### How are you running Gitea? I have tried the downloaded 1.22.0 binary (gitea_1.22.0_dev-1092-g02d4a62e3) along with the nightly build (1.22.0+41-g3fcf865a4b). Gitea is running on a Hyper-V hosted VM (no container), launched as a systemd service (service file included in gist). ### Database MySQL/MariaDB

GiteaMirror added the type/bug issue/workaround labels 2025-11-02 10:32:24 -06:00

GiteaMirror closed this issue

2025-11-02 10:32:24 -06:00

GiteaMirror commented

2025-11-02 10:32:25 -06:00

@wxiaoguang commented on GitHub (Jun 12, 2024):

A workaround is to run the "Sync branches" from the admin dashboard panel.

@wxiaoguang commented on GitHub (Jun 12, 2024): A workaround is to run the "Sync branches" from the admin dashboard panel.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#13139