500 error in renderDirectory(): GetCommitsInfo is trying to get root commit's parent

[wolfgang42]

• Gitea version (or commit ref): 4d2ea7d built with: bindata, sqlite
• Git version: 2.11.2
• Operating system: Ubuntu (Xenial); with Docker
• 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: 2017/06/18 17:00:17 [...routers/repo/view.go:53 renderDirectory()] [E] GetCommitsInfo: exit status 128 - fatal: bad revision '00a3cc4831ab308a739955f6e9eaecdc1198e7bb^'

Description

I have a fairly complex repository (unfortunately not one I can make public) which I recently uploaded to Gitea. For certain directories in the repository (e.g. /wolf/wolf-www/src/master/public_html/inc), I get a 500 error when I attempt to view them. The problem seems to be that it's trying to get 00a3cc4^, but 00a3cc4 is the root of the repository and therefore has no parent commit. This looks vaguely similar to #1836, but it looks like that was a different root cause which has been fixed.

[ethantkoenig]

@wolfgang42 Any chance you could sanitize the repo for us? As far as I can tell, file contents should not matter, only directory/submodule structure. If you clear all file contents (and even change file and directory names, if those are sensitive), that should be enough for us to reproduce the bug.

[wolfgang42]

@ethantkoenig Any suggestions on how to sanitize several hundred commits quickly? It seems that it's not just the current directory structure, I dropped .git and created a new repository and the problem went away, so I think it's something in the history.

[ethantkoenig]

@wolfgang42 Okay, if commit history matters, then sanitizing may not be an option.

Assuming that filenames are not sensitive, could you do the following?

• Check out https://github.com/ethantkoenig/gitea/tree/debug/get_commit_infos (4d2ea7d plus some print statements)
• Trying viewing one of the problematic directories
• Share with me what gets printed (should just be filenames and commit hashes)

That would be very helpful in diagnosing the issue. Thanks!

[wolfgang42]

I'm having trouble building gitea from source--I did make docker but when I run it I get GlobalInit()] [E] Failed to initialize ORM engine: Failed to connect to database: this binary version does not build support for SQLite3. Is there something I need to do to get the image to build with sqlite support?

[ethantkoenig]

@wolfgang42 Try export TAGS='sqlite'? I'm not positive though, I'm not very familiar with docker.

[lafriks]

You need to run:
TAGS="sqlite" make docker

[wolfgang42]

I've got it running now, but I can't figure out where to look for the output from your print statements. I don't see it in either gitea.log or the stdout from the container.

[ethantkoenig]

@wolfgang42 When I run it locally using docker, I see the print statements in the stdout:

$ docker run --name=gitea -p 10022:22 -p 10080:3000 -v /var/lib/gitea:/data gitea/gitea
...
logCommand: state=&{entries:map[file1.txt:0xc42051f500] commits:map[] lastCommitHash: lastCommit:<nil> treePath: headCommit:0xc42064e210 nextSearchSize:16}
logCommand: command=git log --pretty=format:%H --name-only -1 192d874254b2d34b99e66507fda5de90ffd0d56d -- file1.txt
[git-module] /data/git/repositories/user1/repo1.git: git log --pretty=format:%H --name-only -1 192d874254b2d34b99e66507fda5de90ffd0d56d -- file1.txt
[git-module] stdout:
192d874254b2d34b99e66507fda5de90ffd0d56d
file1.txt

getNextCommitInfos: logOuput=[[
192d874254b2d34b99e66507fda5de90ffd0d56d
file1.txt

]]

If you're running docker in detached mode (i.e. -d), then you'll need to use docker logs <container-hash> to see the stdout

[wolfgang42]

I figured it out--I forgot to check out the correct branch! 😳 Having sorted that out, here's the complete log I get when I try to view the page: https://static.linestarve.com/ext/github/gitea-issue2005-log.txt

[ethantkoenig]

@wolfgang42 I think I have a fix. Please pull from the debug branch and let me know if that fixes it.

[wolfgang42]

@ethantkoenig Yep, that fixed it. Thank you!

[lunny]

closed by #2014