500 Error after changing the repository branch #756

@oszilloskop commented on GitHub (May 30, 2017):

This behavior only happens if I within the '<>Code' Tab.
Inside the 'Commits' Tab I can switch to an other branch without a 500 error.

@oszilloskop commented on GitHub (May 30, 2017): This behavior only happens if I within the '<>Code' Tab. Inside the 'Commits' Tab I can switch to an other branch without a 500 error. ![bildschirmfoto](https://cloud.githubusercontent.com/assets/1434390/26607022/ab5a2d82-4594-11e7-8dc7-5e63f65a04a9.png)

GiteaMirror commented

@andreynering commented on GitHub (Jun 3, 2017):

@ethantkoenig I don't know why, but I still 500 errors in some repos in one of my instances:

2017/06/03 14:11:20 [...routers/repo/view.go:53 renderDirectory()] [E] GetCommitsInfo: exit status 128 - fatal: bad revision '28d65e48fe0e8143d2cdf08593f6ab217c282be9^'

Seems the problem is the ending ^?

In the repos I don't get 500 errors, the page never returns and the CPU usage of Gitea process spikes. Seems an infinite loop. This instance is on Windows.

Stangely, it still works on other instances of Gitea. Old version also works fine.

I suggest to revert these changes temporarely, until we got to fix them.

@andreynering commented on GitHub (Jun 3, 2017): @ethantkoenig I don't know why, but I still 500 errors in some repos in one of my instances: > 2017/06/03 14:11:20 [...routers/repo/view.go:53 renderDirectory()] [E] GetCommitsInfo: exit status 128 - fatal: bad revision '28d65e48fe0e8143d2cdf08593f6ab217c282be9^' Seems the problem is the ending `^`? In the repos I don't get 500 errors, the page never returns and the CPU usage of Gitea process spikes. Seems an infinite loop. This instance is on Windows. Stangely, it still works on other instances of Gitea. Old version also works fine. I suggest to revert these changes temporarely, until we got to fix them.

GiteaMirror commented

@ethantkoenig commented on GitHub (Jun 3, 2017):

@andreynering I have a few questions:

In the error message, is 28d65e... the first commit?
Do the working instances of Gitea have the same repositories as the non-working instance? If not, could you try transferring some of the problematic repos to a working instance to see what happens?
What is the configuration of the problematic instance? Are you able to reproduce the 500/infinite loops in an another, similarly-configured instance?

@ethantkoenig commented on GitHub (Jun 3, 2017): @andreynering I have a few questions: 1. In the error message, is `28d65e...` the first commit? 2. Do the working instances of Gitea have the same repositories as the non-working instance? If not, could you try transferring some of the problematic repos to a working instance to see what happens? 3. What is the configuration of the problematic instance? Are you able to reproduce the 500/infinite loops in an another, similarly-configured instance?

GiteaMirror commented

@andreynering commented on GitHub (Jun 4, 2017):

@ethantkoenig

In the error message, is 28d65e... the first commit?

No, it's not. Actually, it's a very old commit, from about 1 month ago.

Do the working instances of Gitea have the same repositories as the non-working instance? If not, could you try transferring some of the problematic repos to a working instance to see what happens?

Other repos, but tried and works fine on other instance, also if I rollback to old Gitea version. I don't think the repos are the problem.

What is the configuration of the problematic instance? Are you able to reproduce the 500/infinite loops in an another, similarly-configured instance?

Mostly the default options. I could not reproduce in another instance, even on Windows.

@andreynering commented on GitHub (Jun 4, 2017): @ethantkoenig > In the error message, is 28d65e... the first commit? No, it's not. Actually, it's a very old commit, from about 1 month ago. > Do the working instances of Gitea have the same repositories as the non-working instance? If not, could you try transferring some of the problematic repos to a working instance to see what happens? Other repos, but tried and works fine on other instance, also if I rollback to old Gitea version. I don't think the repos are the problem. > What is the configuration of the problematic instance? Are you able to reproduce the 500/infinite loops in an another, similarly-configured instance? Mostly the default options. I could not reproduce in another instance, even on Windows.

GiteaMirror commented

@andreynering commented on GitHub (Jun 4, 2017):

I also tried to update to latest version of Git with no change.

@andreynering commented on GitHub (Jun 4, 2017): I also tried to update to latest version of Git with no change.

GiteaMirror commented

@ethantkoenig commented on GitHub (Jun 4, 2017):

@andreynering Sorry, I should have been more clear; by "first" I meant the oldest commit (i.e. the very first commit made to the repo), not the latest commit

@ethantkoenig commented on GitHub (Jun 4, 2017): @andreynering Sorry, I should have been more clear; by "first" I meant the oldest commit (i.e. the very first commit made to the repo), not the latest commit

GiteaMirror commented

@andreynering commented on GitHub (Jun 4, 2017):

Oh, yes, it is the first commit of this repo.

@andreynering commented on GitHub (Jun 4, 2017): Oh, yes, it is the first commit of this repo.

GiteaMirror commented

@ethantkoenig commented on GitHub (Jun 4, 2017):

@andreynering Could you do the following:

Add the following print statement to the top of the logCommand(..) function in vendor/code.gitea.io/git/tree_entry.go (line 266):

fmt.Printf("logCommand: startHash=%s, state=%+v\n", exclusiveStartHash, state)

Re-run on one the repos that causes an infinite loop
Let me know what get's printed
Post that repo to somewhere I can access it (e.g. try.gitea.io).

Since I don't think I'll be able to reproduce the bug locally, we'll unfortunately need to resort to some form of remote debugging.

@ethantkoenig commented on GitHub (Jun 4, 2017): @andreynering Could you do the following: 1. Add the following print statement to the top of the `logCommand(..)` function in `vendor/code.gitea.io/git/tree_entry.go` (line 266): ``` fmt.Printf("logCommand: startHash=%s, state=%+v\n", exclusiveStartHash, state) ``` 2. Re-run on one the repos that causes an infinite loop 3. Let me know what get's printed 4. Post that repo to somewhere I can access it (e.g. try.gitea.io). Since I don't think I'll be able to reproduce the bug locally, we'll unfortunately need to resort to some form of remote debugging.

GiteaMirror commented

@andreynering commented on GitHub (Jun 5, 2017):

Unfortunaly I can't make this repos public. I'll try with open source ones later.

Also the log contains filenames, so I'll omit. But it prints the same thing over and over again.

After some debugging seems this line causes the infinite loop.

@andreynering commented on GitHub (Jun 5, 2017): Unfortunaly I can't make this repos public. I'll try with open source ones later. Also the log contains filenames, so I'll omit. But it prints the same thing over and over again. After some debugging seems [this line causes the infinite loop](https://github.com/go-gitea/gitea/blob/ca9169fbe9be5aab47a5feabb4df8cbbe1fb4d9d/vendor/code.gitea.io/git/tree_entry.go#L233).

GiteaMirror commented

@ethantkoenig commented on GitHub (Jun 5, 2017):

@andreynering Could you show the exact line that gets printed over and over? If you have to sanitize filenames, that's fine

@ethantkoenig commented on GitHub (Jun 5, 2017): @andreynering Could you show the exact line that gets printed over and over? If you have to sanitize filenames, that's fine

GiteaMirror commented

@andreynering commented on GitHub (Jun 5, 2017):

@ethantkoenig

Here's the log.

@andreynering commented on GitHub (Jun 5, 2017): @ethantkoenig [Here's the log][log]. [log]: https://gist.githubusercontent.com/andreynering/488107906d692956d2130daa9c50ee8a/raw/f01001f8474a8b932624a93aad5bd366007f8181/infinite_loop.log

GiteaMirror commented

@ethantkoenig commented on GitHub (Jun 5, 2017):

@andreynering Thank you! I think I've found the bug, can you confirm that https://github.com/go-gitea/git/pull/59 fixes the problem?

@ethantkoenig commented on GitHub (Jun 5, 2017): @andreynering Thank you! I think I've found the bug, can you confirm that https://github.com/go-gitea/git/pull/59 fixes the problem?

GiteaMirror commented

@lafriks commented on GitHub (Jun 6, 2017):

@appleboy this issue can't be closed while gitea git godep is not updated

@lafriks commented on GitHub (Jun 6, 2017): @appleboy this issue can't be closed while gitea git godep is not updated

GiteaMirror commented

@appleboy commented on GitHub (Jun 6, 2017):

@lafriks OK. reopened.

@appleboy commented on GitHub (Jun 6, 2017): @lafriks OK. reopened.

GiteaMirror commented

@andreynering commented on GitHub (Jun 6, 2017):

@ethantkoenig Sorry for the delay. https://github.com/go-gitea/git/pull/59 fixed the issue. https://github.com/go-gitea/gitea/pull/1888 updates git package.

Thank you very much.

@andreynering commented on GitHub (Jun 6, 2017): @ethantkoenig Sorry for the delay. https://github.com/go-gitea/git/pull/59 fixed the issue. https://github.com/go-gitea/gitea/pull/1888 updates `git` package. Thank you very much.

GiteaMirror commented