Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Seg Fault redux? #2728

Closed
2 of 7 tasks
quasiben opened this issue Oct 17, 2017 · 17 comments · Fixed by #2752
Closed
2 of 7 tasks

Seg Fault redux? #2728

quasiben opened this issue Oct 17, 2017 · 17 comments · Fixed by #2752
Labels
Milestone

Comments

@quasiben
Copy link

Description

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

@quasiben
Copy link
Author

I have also tried with 1.1.4

@quasiben
Copy link
Author

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

@lafriks
Copy link
Member

lafriks commented Oct 17, 2017

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

@quasiben
Copy link
Author

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 :/

@quasiben
Copy link
Author

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:

@pgaskin
Copy link
Contributor

pgaskin commented Oct 18, 2017

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

@pgaskin
Copy link
Contributor

pgaskin commented Oct 18, 2017

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.

@quasiben
Copy link
Author

@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

@pgaskin
Copy link
Contributor

pgaskin commented Oct 18, 2017

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

@quasiben
Copy link
Author

Was golang 1.8.X used to build binaries ?

@pgaskin
Copy link
Contributor

pgaskin commented Oct 18, 2017

@quasiben not the most recent ones.

@quasiben
Copy link
Author

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

@quasiben
Copy link
Author

I resolved things by setting

export PGPASSFILE="$HOME/.pgpass"

and a colleague submitted an upstream patch: lib/pq#666

@necaris
Copy link

necaris commented Oct 18, 2017

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

@pgaskin
Copy link
Contributor

pgaskin commented Oct 18, 2017

@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

@lafriks lafriks added this to the 1.x.x milestone Oct 18, 2017
@necaris
Copy link

necaris commented Oct 20, 2017

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

@sapk
Copy link
Member

sapk commented Oct 20, 2017

@necaris yes and done (waiting LGTM).

@lunny lunny modified the milestones: 1.x.x, 1.3.0 Oct 21, 2017
@go-gitea go-gitea locked and limited conversation to collaborators Nov 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants