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

Using release binary on armv7 fails with segmentation fault #6700

Open
jlelse opened this issue Apr 21, 2019 · 12 comments

Comments

9 participants
@jlelse
Copy link

commented Apr 21, 2019

I tried upgrading my Gitea Dockerfile for armv7 (based on Alpine) which uses the binary from the release page from 1.7.6 to 1.8.0, but starting Gitea failed.

I was able to reproduce it in an empty alpine container on the armv7 machine by downloading the 1.7.6 binary and executing it - that works without problems, but downloading and executing the 1.8.0 binary fails with a "segmentation fault".

What can be the problem?

Edit: I just tried it in an ubuntu container too, same problem, so it seems like there's something wrong with the binary.

@jlelse

This comment has been minimized.

Copy link
Author

commented Apr 21, 2019

My current workaround is to use the arm-6 binary.

@vmario89

This comment has been minimized.

Copy link

commented Apr 21, 2019

Hi, i got the same problem. I am running Gitea on Xubuntu 18 (odroid platform armv7). The newest 1.8.0 armv7 fails to start with segmentation fault and without any additional comment / stacktrace. I tried with different go versions, but no difference (1.12.1, 1.12.4). It already occured on beta releases 1.8; reverting back to 1.7.5 works fine.

Apr 21 13:49:11 git-droid snoopy[32106]: [login:(unknown) ssh:((undefined)) sid:32106 tty:(none) ((none)/(none)) uid:git(1003)/git(1003) cwd:/opt/gitea]: /opt/gitea/gitea
Apr 21 13:49:11 git-droid systemd[1]: gitea.service: Main process exited, code=killed, status=11/SEGV
Apr 21 13:49:11 git-droid systemd[1]: gitea.service: Failed with result 'signal'.
Apr 21 13:49:11 git-droid systemd[1]: gitea.service: Service hold-off time over, scheduling restart.
Apr 21 13:49:11 git-droid systemd[1]: gitea.service: Scheduled restart job, restart counter is at 5.
Apr 21 13:49:11 git-droid systemd[1]: Stopped Gitea.
Apr 21 13:49:11 git-droid systemd[1]: gitea.service: Start request repeated too quickly.
Apr 21 13:49:11 git-droid systemd[1]: gitea.service: Failed with result 'signal'.
Apr 21 13:49:11 git-droid systemd[1]: Failed to start Gitea.

Now i solved the problem like @jlelse did, to use armv6 - works!. But i guess its not the best solution.

regards, Mario

@lunny

This comment has been minimized.

Copy link
Member

commented Apr 21, 2019

Yes, we ever have an issue to report that before v1.8.0 release. It maybe related with our cross-platform compile.

@jlelse

This comment has been minimized.

Copy link
Author

commented Apr 21, 2019

I'm sorry I didn't report this before, but I didn't try any beta release to wait for the final one.

@focmb

This comment has been minimized.

Copy link

commented Apr 22, 2019

Same here on a raspberry with gitea 1.8.0 arm v7

@Akcaxup

This comment has been minimized.

Copy link

commented Apr 23, 2019

On RaspberryPi Gitea 1.8.0 armv7 failed start without any messages in logs. Gitea 1.7.6 works greate

@sorin-p

This comment has been minimized.

Copy link

commented Apr 24, 2019

Hi guys.

Can this be fixed by just rebuilding the code from "v1.8.0" branch with the latest version of go compiler (1.12.4) on a Linux x86 machine (with GOOS, and GOARCH set for linux/arm), or does it need some changes in the source code as well?
Thanks.

@zeripath

This comment has been minimized.

Copy link
Contributor

commented Apr 24, 2019

For those new to this issue armv6 works.

The issue is apparently something to do with our building environment. The segfault happens extremely early and appears to be when we assign the data segment value main.Version on line 28 however this may simply be first running line of the go program - so I'm not sure whether that's just poor information.

I guess an option might be to try to run the Gitea program from within an unreadable directory - if that panics from within Macaron (which is known about) rather than segfaults - then we know it's something to do with main.Version. In which case the problem would likely be the linker and its override of main.Version - either we aren't telling the linker that this is an armv7 binary and its detection is wrong or its making an incorrect assumption about where to put the override - if not then it could still be something to do with that but it's less suspicious. It doesn't panic - the segfault still happens earliest.

Other putative causes such as glibc version, kernel version have been suggested but I'm not certain about this as people seem to be able to cross-compile without hitting this bug.

Anyway the armv6 binary works for the raspberry pi so that is the suggested workaround until we get some more information.

@zeripath

This comment has been minimized.

Copy link
Contributor

commented Apr 24, 2019

@sorin-p I believe just building it should work.

@Josue-T

This comment has been minimized.

Copy link

commented May 8, 2019

I have the same issue with the version 1.8.0 and 1.8.1

@sorin-p

This comment has been minimized.

Copy link

commented May 8, 2019

Hi guys.
I can confirm, build 1.8.1 fails with "Bus error" while using armv7 binary, and using armv6 binary works fine.

watson81 added a commit to watson81/docker-gitea-rpi that referenced this issue May 9, 2019

Update to Gitea 1.8.1, switch to ARM 6
Updating to Gitea 1.8.1: https://blog.gitea.io/2019/05/gitea-1.8.1-is-released/
Unfortunately, Gitea's ARM 7 release still does not run; see go-gitea/gitea#6700. So, this container now uses arm6 instead.
@rbouikila

This comment has been minimized.

Copy link

commented May 13, 2019

I have the same issue with the version 1.8.0 and 1.8.1 on armbian.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.