Gitea: Seg Fault redux?

Created on 17 Oct 2017  路  17Comments  路  Source: go-gitea/gitea

Gitea dies in the middle of starting up. Not exactly sure how to diagnose this issue. Could
issue #1684 be related ?

kinbug

Most helpful comment

I resolved things by setting

export PGPASSFILE="$HOME/.pgpass"

and a colleague submitted an upstream patch: https://github.com/lib/pq/pull/666

All 17 comments

I have also tried with 1.1.4

I'm running a simpler version and I'm seeing a different error:

[root@ap-gitea-2361316594-z8612]# gitea web
2017/10/17 18:36:32 [...s/setting/setting.go:801 NewContext()] [E] Expect user 'root' but current user is:
[root@ap-gitea-2361316594-z8612]# whoami
root

This is running in a Centos 7.3 docker image which I've deployed with Kubernetes. Something wonky appears to be happening with how the current user is being determined here

User on Linux is determined by checking environment variables USER and USERNAME. Could be that centos does not set them?

Ah, right. I have a script that was injecting that env var and now I'm back to the original seg fault posted at the top :/

Switching to 1.2.1 I get the error:

2017/10/17 20:39:24 [I] [SQL] SELECT "user".id FROM "user" WHERE "user".num_repos!=(SELECT COUNT(*) FROM "repository" WHERE owner_id="user".id)
2017/10/17 20:39:24 [...els/issue_indexer.go:89 InitIssueIndexer()] [E] InitIssuesIndexer, open index: error parsing mapping JSON: unexpected end of JSON input
mapping contents:

For the 1.2.1 indexer error, you can fix it by deleting the /path/to/gitea/data/dir/indexers/issues.bleve folder and restarting gitea.

For the segfault, try running gitea in gdb, and see if there is a null value in a variable on one of the stack frames (google it, you'll find lots of stuff about debugging segfaults with gdb).

According to your stack trace:

/usr/local/go/src/os/user/lookup_unix.go:253 +0x2b fp=0xc42012d4e8 sp=0xc42012d480 os/user.lookupUnixUid(0x0, 0x0, 0x0, 0x0) /usr/local/go/src/os/user/lookup_unix.go:105 +0x161 fp=0xc42012d5b0 sp=0xc42012d4e8 os/user.current(0x0, 0x0, 0xc42013d700) /usr/local/go/src/os/user/lookup_unix.go:49 +0x2f fp=0xc42012d5e0 sp=0xc42012d5b0 os/user.Current(0x131e8e8, 0xa, 0x0)

user.lookupUnixUid seems to be passed nil values for arguments. The code for user.lookupUnixUid is here. user.Current calls syscall.Getuid, which should return an integer with the uid. Instead, it seems to be returning nil. I'm not sure what is going on here more than what I just said. This may somewhat be related to golang/go#13470.

I am not completely certain if this is the issue, as I only occasionally debug segfaults, and it is usually with a debugger like gdb or delve, not by reading stack traces.

@geek1011, thanks for the comments. I'm pretty sure the issue is as you described -- the user.lookupUnixUid is coming back with nil values. Which version of go was used when building the gitea binary ?

Apologies, I am unfamiliar with golang. I'm trying to build master with golang 1.8.3 but I get an error:

go build -i -v  -tags '' -ldflags '-s -w -X "main.Version=1.1.0+644-g2a184f59" -X "main.Tags="' -o gitea
code.gitea.io/gitea/vendor/github.com/chaseadamsio/goorgeous
code.gitea.io/gitea/modules/markup/orgmode
_/root/gitea
# _/root/gitea
./main.go:40: cannot use cmd.CmdWeb (type "code.gitea.io/gitea/vendor/github.com/urfave/cli".Command) as type "github.com/urfave/cli".Command in array or slice literal

@quasiben you need go 1.9.1 to build the latest urfave.cli. I recently ran into this issue myself.

Was golang 1.8.X used to build binaries ?

@quasiben not the most recent ones.

Ok.

Still seeing errors with 1.9.1

[root@2361316594-z8612 gitea]# go version
go version go1.9.1 linux/amd64
[root@ap-git-storage-2361316594-z8612 gitea]# make
go build -i -v  -tags '' -ldflags '-s -w -X "main.Version=1.1.0+644-g2a184f59" -X "main.Tags="' -o gitea
_/root/gitea
# _/root/gitea
./main.go:40:6: cannot use cmd.CmdWeb (type "code.gitea.io/gitea/vendor/github.com/urfave/cli".Command) as type "github.com/urfave/cli".Command in array or slice literal

But, perhaps upgrading to 1.9.1 won't actually solve my problem here

I resolved things by setting

export PGPASSFILE="$HOME/.pgpass"

and a colleague submitted an upstream patch: https://github.com/lib/pq/pull/666

Is there a place where this can be documented so that people can find this workaround in future?

@quasiben Great job. I guess my analysis of the stack trace was correct.

@necaris This workaround may not be needed in the future because of lib/pq#666

Note that https://github.com/lib/pq/pull/666 has been merged -- does there need to be some kind of govendor update to ensure this is picked up by gitea?

@necaris yes and done (waiting LGTM).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

thehowl picture thehowl  路  3Comments

kifirkin picture kifirkin  路  3Comments

BNolet picture BNolet  路  3Comments

internalfx picture internalfx  路  3Comments

flozz picture flozz  路  3Comments