Tons of panic errors with GZIP enabled #4321

New Issue

GiteaMirror · 2025-11-02T05:45:58-06:00

GiteaMirror commented

2025-11-02 05:45:58 -06:00

Originally created by @HorlogeSkynet on GitHub (Nov 14, 2019).

Gitea version (or commit ref): v1.10.0
Git version: v2.20.1
Operating system: Debian Buster
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist: https://pastebin.com/48z5b0FL

Description

Hey everyone !
It seems like there has been some issues with GZIP for some minor versions from now.
I can't really figure out since when, as logs have been polluted and rotated for weeks.
The error attached above is thrown every ~20 seconds when GZIP is enabled on my setup.
Still happening against v1.9.6 and v1.10.0 .

I can provide further details if you guys got some ideas to narrow down the diagnostic.

Bye, thanks 👋

Originally created by @HorlogeSkynet on GitHub (Nov 14, 2019).   - Gitea version (or commit ref): v1.10.0 - Git version: v2.20.1 - Operating system: Debian Buster - Database (use `[x]`): - [X] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [X] Not relevant - Log gist: <https://pastebin.com/48z5b0FL> ## Description Hey everyone ! It seems like there has been some issues with GZIP for some minor versions from now. I can't really figure out since _when_, as logs have been polluted and rotated for weeks. The error attached above is thrown every ~20 seconds when GZIP is enabled on my setup. Still happening against v1.9.6 and v1.10.0 . I can provide further details if you guys got some ideas to narrow down the diagnostic. Bye, thanks 👋

GiteaMirror added the issue/confirmed type/bug labels 2025-11-02 05:45:58 -06:00

GiteaMirror closed this issue

2025-11-02 05:45:58 -06:00

GiteaMirror commented

2025-11-02 05:45:59 -06:00

@zeripath commented on GitHub (Nov 14, 2019):

Ok. We need the precise version of Gitea. routers/repo/repo.go appears to be one of the more active parts of our code so line 342 isn't too helpful.

Do you have a SHA hash for the commit that made those logs?

@zeripath commented on GitHub (Nov 14, 2019): Ok. We need the precise version of Gitea. routers/repo/repo.go appears to be one of the more active parts of our code so line 342 isn't too helpful. Do you have a SHA hash for the commit that made those logs?

GiteaMirror commented

2025-11-02 05:45:59 -06:00

@zeripath commented on GitHub (Nov 14, 2019):

It would also be helpful to see the router logs and surrounding logging

@zeripath commented on GitHub (Nov 14, 2019): It would also be helpful to see the router logs and surrounding logging

GiteaMirror commented

2025-11-02 05:45:59 -06:00

@zeripath commented on GitHub (Nov 14, 2019):

Assuming that 1.10 produced that log the implication is that this caused the panic:

9619ccf0e5/routers/repo/repo.go (L342)

Which doesn't exactly make a lot of sense

@zeripath commented on GitHub (Nov 14, 2019): Assuming that 1.10 produced that log the implication is that this caused the panic: https://github.com/go-gitea/gitea/blob/9619ccf0e54c0f8502b5e1bc7dad4d3471330f9c/routers/repo/repo.go#L342 Which doesn't exactly make a lot of sense

GiteaMirror commented

2025-11-02 05:46:00 -06:00

@zeripath commented on GitHub (Nov 14, 2019):

Basically either ctx.User is nil or ctx.Repo.Repository / ctx.Repo is nil.

@zeripath commented on GitHub (Nov 14, 2019): Basically either ctx.User is nil or ctx.Repo.Repository / ctx.Repo is nil.

GiteaMirror commented

2025-11-02 05:46:00 -06:00

@zeripath commented on GitHub (Nov 14, 2019):

Assuming that is the causative line, repo.Action matches the following endpoint:

9619ccf0e5/routers/routes/routes.go (L684)

@zeripath commented on GitHub (Nov 14, 2019): Assuming that is the causative line, repo.Action matches the following endpoint: https://github.com/go-gitea/gitea/blob/9619ccf0e54c0f8502b5e1bc7dad4d3471330f9c/routers/routes/routes.go#L684

GiteaMirror commented

2025-11-02 05:46:00 -06:00

@zeripath commented on GitHub (Nov 14, 2019):

Which sort of implies that you're try to star a repository but why would you be doing that so often... It's weird.

@zeripath commented on GitHub (Nov 14, 2019): Which sort of implies that you're try to star a repository but why would you be doing that so often... It's weird.

GiteaMirror commented

2025-11-02 05:46:00 -06:00

@HorlogeSkynet commented on GitHub (Nov 14, 2019):

It's definitely v1.10.0 .
It looks like my instance is being hard-crawled (so huge amount of unauthenticated requests) for some days now (🤷‍♂).

By increasing the log level, I've managed to reproduce the error on my own.
It appears when requesting something like : https://$HOSTNAME/$OWNER/$REPOSITORY/action/watch?redirect_to=$URL_ENCODED_FILE_LOCATION.
Symmetrically, as you pointed out, trying to star is equivalent.
Errors come up, but the back-end correctly redirects to the authentication page.

So, is it just about a null-able variable being used somewhere ?

Thanks for the quick feedback @zeripath 🙇

EDIT (important) : With GZIP disabled, I still cannot reproduce the behavior.

@HorlogeSkynet commented on GitHub (Nov 14, 2019): It's definitely v1.10.0 . It looks like my instance is being hard-crawled (so huge amount of unauthenticated requests) for some days now (🤷‍♂). By increasing the log level, I've managed to reproduce the error on my own. It appears when requesting something like : `https://$HOSTNAME/$OWNER/$REPOSITORY/action/watch?redirect_to=$URL_ENCODED_FILE_LOCATION`. Symmetrically, as you pointed out, trying to star is equivalent. Errors come up, but the back-end correctly redirects to the authentication page. So, is it _just_ about a null-able variable being used somewhere ? Thanks for the quick feedback @zeripath 🙇 EDIT (important) : With `GZIP` disabled, I still cannot reproduce the behavior.

GiteaMirror commented

2025-11-02 05:46:00 -06:00

@zeripath commented on GitHub (Nov 14, 2019):

It's weird it's like things are not being cancelled when the user is denied - I'll have to take a look.

@zeripath commented on GitHub (Nov 14, 2019): It's weird it's like things are not being cancelled when the user is denied - I'll have to take a look.

GiteaMirror commented

2025-11-02 05:46:01 -06:00

@zeripath commented on GitHub (Nov 15, 2019):

Ah damn... When I reimplemented this I just copied the behaviour that was there before...

it was wrong then and it is wrong now.

We need to actually properly implement all the context response writer methods - or - change the internal writer of the context response writer.

@zeripath commented on GitHub (Nov 15, 2019): Ah damn... When I reimplemented this I just copied the behaviour that was there before... it was wrong then and it is wrong now. We need to actually properly implement all the context response writer methods - or - change the internal writer of the context response writer.

GiteaMirror commented

2025-11-02 05:46:01 -06:00

@HorlogeSkynet commented on GitHub (Nov 15, 2019):

Thanks again @zeripath, that was awesome and quick 👌
Can't wait to see the next release being drafted !
@++ 👋

@HorlogeSkynet commented on GitHub (Nov 15, 2019): Thanks again @zeripath, that was awesome and quick 👌 Can't wait to see the next release being drafted ! @++ 👋

GiteaMirror referenced this issue

2025-11-02 12:32:45 -06:00

[PR #4321] [MERGED] add 1.4.3 changelog #17330

GiteaMirror referenced this issue

2025-11-02 12:32:46 -06:00

[PR #4323] [MERGED] Backport 1.4.3 changelog to master branch #17331

Sign in to join this conversation.