Gitea 1.17-dev crashing Out of memory #19793
Labels
issue/critical
This issue should be fixed ASAP. If it is a PR, the PR should be merged ASAP
issue/regression
Issue needs no code to be fixed, only a description on how to fix it yourself
type/bug
Comments
|
Suspecting /user/events ( which looks like a stream ) after checking logs at https://gist.github.com/gboddin/7956cd755b034c1b399672c1abc6ab2f |
|
Happened 3 more times when checking an issue and hitting the browser Back button |
gboddin
changed the title
|
Ok I crashed the test instance. |
lafriks
added
the
issue/critical
|
Commented We needed packages more than notifications and stopwatches :) Let us know if we can provide anything else to help with 1.17 ! |
|
Can reproduce locally as well by just starting my dev instance gitea. A lot of goroutines of crashInterestingly, crash did not occur again on second startup. |
|
Agh I hit this a few days ago whilst I was in debug mode but thought it was due to too many checkpoints. This is a regression from #19748 but it is looping because of a mistake in #10961 The problem is in here: c.Data["NotificationUnreadCount"] = func() int64 {
count, err := models.GetNotificationCount(c, c.Doer, models.NotificationStatusUnread)
if err != nil {
c.ServerError("GetNotificationCount", err)
return -1
}
return count
}The function here is called during rendering. If there is an err it's too late really to use ServerError as we're already rendering - and we should simply return -1 here and log the problem. I'll pop up a PR. |
zeripath
added a commit
to zeripath/gitea
that referenced
this issue
May 24, 2022
If the context is cancelled `.NotificationUnreadCount` in a template can cause an infinite loop with `ctx.ServerError()` being called, which creates a template that then calls `.NotificationUnreadCount` calling `GetNotificationCount()` with the cancelled context resulting in an error that calls `ctx.ServerError`... and so on... This PR simply stops calling `ctx.ServerError` in the error handler code for `.NotificationUnreadCount` as we have already started rendering and so it is too late to call `ctx.ServerError`. Additionally we skip logging the error if it's a context cancelled error. Fix go-gitea#19793 Signed-off-by: Andrew Thornton <art27@cantab.net>
zeripath
added
the
issue/regression
|
As the bug is a regression due to unreleased code the PR to fix it has been marked skip-changelog. |
lunny
pushed a commit
that referenced
this issue
May 25, 2022
If the context is cancelled `.NotificationUnreadCount` in a template can cause an infinite loop with `ctx.ServerError()` being called, which creates a template that then calls `.NotificationUnreadCount` calling `GetNotificationCount()` with the cancelled context resulting in an error that calls `ctx.ServerError`... and so on... This PR simply stops calling `ctx.ServerError` in the error handler code for `.NotificationUnreadCount` as we have already started rendering and so it is too late to call `ctx.ServerError`. Additionally we skip logging the error if it's a context cancelled error. Fix #19793 Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
|
I think the problem is |
If we could add a linter rule for that, that'd be great. |
|
Thank you so much for the quick response and the details ! I know a bit more if I need to help on a PR next time :) |
I don't think that would be very easy. I think we have a couple of options:
|
AbdulrhmnGhanem
pushed a commit
to kitspace/gitea
that referenced
this issue
Aug 24, 2022
…9799) If the context is cancelled `.NotificationUnreadCount` in a template can cause an infinite loop with `ctx.ServerError()` being called, which creates a template that then calls `.NotificationUnreadCount` calling `GetNotificationCount()` with the cancelled context resulting in an error that calls `ctx.ServerError`... and so on... This PR simply stops calling `ctx.ServerError` in the error handler code for `.NotificationUnreadCount` as we have already started rendering and so it is too late to call `ctx.ServerError`. Additionally we skip logging the error if it's a context cancelled error. Fix go-gitea#19793 Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
Gitea starts what seems like an infinite loop and runs out of memory,
Issues happend 3 times, randomly browsing the instance, no pattern noticed.
Will update if a pattern is found
Gitea Version
7671a33
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
https://gist.github.com/gboddin/7956cd755b034c1b399672c1abc6ab2f
Screenshots
Nothing to see, gitea hangs until OOM kills it
Git Version
git version 2.30.2
Operating System
debian-bullseye
How are you running Gitea?
TAGS="bindata sqlite sqlite_unlock_notify" make buildDatabase
SQLite
The text was updated successfully, but these errors were encountered: