500 Error after changing the repository branch

[oszilloskop]

• Gitea version (or commit ref): master (642f844)
• Git version: 2.1.4
• Operating system: Debian 8.8
• 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:

Description

I forked/cloned a repository from Github to Gitea.

If I switch within this repository from the master branch to an other branch or tag then I got a 500 Error Website.
It could be that my repository is very screwed-up but I need the other branches :o)

You can find the repository here: https://try.gitea.io/oszilloskop/site-ffffm

[oszilloskop]

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.

[andreynering]

@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.

[ethantkoenig]

@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?

[andreynering]

@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]

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

[ethantkoenig]

@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

[andreynering]

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

[ethantkoenig]

@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.

[andreynering]

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.

[ethantkoenig]

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

[andreynering]

@ethantkoenig

Here's the log.

[ethantkoenig]

@andreynering Thank you! I think I've found the bug, can you confirm that go-gitea/git#59 fixes the problem?

[lafriks]

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

[appleboy]

@lafriks OK. reopened.

[andreynering]

@ethantkoenig Sorry for the delay. go-gitea/git#59 fixed the issue. #1888 updates git package.

Thank you very much.

[andreynering]

Ops, now there's infine loops while listing some repo folders. But #1888 can be merged first.