Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1091538
Summary: | golang crashing on ARMv7 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Peter Robinson <pbrobinson> |
Component: | golang | Assignee: | Vincent Batts <vbatts> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 22 | CC: | adam, admiller, golang-updates, jkeck, lemenkov, renich, s, vbatts |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-07-19 11:24:36 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 245418, 467765, 1071880, 922257 |
Description
Peter Robinson
2014-04-25 19:54:11 UTC
Wacky. I wonder what code it is compiling/running to get a panic on a syscall ... Peter, code you paste the code from the swig class.actionexample ? (In reply to Peter Robinson from comment #0) > We're getting an crash with go when I try and enable go support for ARM in > the swig package. > > http://koji.fedoraproject.org/koji/taskinfo?taskID=6780663 > > It's currently just a scratch build as I obviously can't push it if it fails. > > checking Examples/go/callback > checking Examples/go/class > unexpected fault address 0x40440000 > fatal error: fault > [signal 0xb code=0x1 addr=0x40440000 pc=0x40440000] > goroutine 1 [running]: > runtime.throw(0x15691f) > /usr/lib/golang/src/pkg/runtime/panic.c:464 +0x5c fp=0xb6ba5f7c > runtime: unexpected return pc for runtime.sigpanic called from 0x40440000 > runtime.sigpanic() > /usr/lib/golang/src/pkg/runtime/os_linux.c:237 +0xa8 fp=0xb6ba5f88 > goroutine 3 [syscall]: > runtime.goexit() > /usr/lib/golang/src/pkg/runtime/proc.c:1394 > checking Examples/go/constants > make[3]: *** [go_run] Error 2 > make[2]: *** [check] Error 2 > make[1]: *** [class.actionexample] Error 2 > checking Examples/go/enum > checking Examples/go/extend > checking Examples/go/funcptr > checking Examples/go/multimap > checking Examples/go/pointer > checking Examples/go/reference > checking Examples/go/simple > checking Examples/go/template > checking Examples/go/variables (In reply to Vincent Batts from comment #1) > Wacky. I wonder what code it is compiling/running to get a panic on a > syscall ... > > Peter, code you paste the code from the swig class.actionexample ? Can't you retrieve it from the .src.rpm? Peter Robinson, Is this still an issue on swig-3.0.2-1? looks like Swig is building clean lately http://koji.fedoraproject.org/koji/packageinfo?packageID=400 (In reply to Peter Robinson from comment #0) > We're getting an crash with go when I try and enable go support for ARM in > the swig package. > > http://koji.fedoraproject.org/koji/taskinfo?taskID=6780663 > > It's currently just a scratch build as I obviously can't push it if it fails. > > checking Examples/go/callback > checking Examples/go/class > unexpected fault address 0x40440000 > fatal error: fault > [signal 0xb code=0x1 addr=0x40440000 pc=0x40440000] > goroutine 1 [running]: > runtime.throw(0x15691f) > /usr/lib/golang/src/pkg/runtime/panic.c:464 +0x5c fp=0xb6ba5f7c > runtime: unexpected return pc for runtime.sigpanic called from 0x40440000 > runtime.sigpanic() > /usr/lib/golang/src/pkg/runtime/os_linux.c:237 +0xa8 fp=0xb6ba5f88 > goroutine 3 [syscall]: > runtime.goexit() > /usr/lib/golang/src/pkg/runtime/proc.c:1394 > checking Examples/go/constants > make[3]: *** [go_run] Error 2 > make[2]: *** [check] Error 2 > make[1]: *** [class.actionexample] Error 2 > checking Examples/go/enum > checking Examples/go/extend > checking Examples/go/funcptr > checking Examples/go/multimap > checking Examples/go/pointer > checking Examples/go/reference > checking Examples/go/simple > checking Examples/go/template > checking Examples/go/variables (In reply to Vincent Batts from comment #3) > Peter Robinson, Is this still an issue on swig-3.0.2-1? looks like Swig is > building clean lately > http://koji.fedoraproject.org/koji/packageinfo?packageID=400 Only because go was disabled. I'll retest and update It still fails. http://koji.fedoraproject.org/koji/taskinfo?taskID=7058479 You can test yourself with the following change to the swig spec file: diff --git a/swig.spec b/swig.spec index 7c1b180..5bc6105 100644 --- a/swig.spec +++ b/swig.spec @@ -6,7 +6,7 @@ %{!?lualang:%global lualang 1} %{!?rubylang:%global rubylang 1} -%ifarch aarch64 %{arm} ppc64le ppc %{power64} s390 s390x +%ifarch aarch64 ppc %{power64} s390 s390x %{!?golang:%global golang 0} %{!?Rlang:%global Rlang 0} %{!?javalang:%global javalang 0} This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22 (In reply to Peter Robinson from comment #5) > It still fails. > > http://koji.fedoraproject.org/koji/taskinfo?taskID=7058479 > > You can test yourself with the following change to the swig spec file: > > diff --git a/swig.spec b/swig.spec > index 7c1b180..5bc6105 100644 > --- a/swig.spec > +++ b/swig.spec > @@ -6,7 +6,7 @@ > %{!?lualang:%global lualang 1} > %{!?rubylang:%global rubylang 1} > > -%ifarch aarch64 %{arm} ppc64le ppc %{power64} s390 s390x > +%ifarch aarch64 ppc %{power64} s390 s390x > %{!?golang:%global golang 0} > %{!?Rlang:%global Rlang 0} > %{!?javalang:%global javalang 0} Peter, there has been a lot of upstream improvements on arm. Can you retest?
> Peter, there has been a lot of upstream improvements on arm. Can you retest?
It's going to take me a while to get to this, you could just drop the %{arm} conditional and do a scratch build to see if it works.
In actual fact looking at the conditional it could likely be dropped entirely as we have golang on aarch64/Power64 since then and gcc-go on s390(x) too so in theory they should be supportable on all of the arches now.
Adding the other arches as someone might have some cycles to review them.
> Peter, there has been a lot of upstream improvements on arm. Can you retest? So kicked off some scratch builds with this diff enabling it on ppc64/ppc64le/s390x/aarch64/armv7. -%ifarch aarch64 %{arm} %{mips} ppc64le ppc %{power64} s390 s390x +%ifarch %{mips} ppc s390 %{!?golang:%global golang 0} aarch64: looks to be some java issues http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=3537366 power64: golang issues http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3366693 s390x: looks to needs some conditionals to use gcc-go http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=2221906 ARMv7: still building http://koji.fedoraproject.org/koji/taskinfo?taskID=13973607 I suspect it's probably worthwhile to untangle the golang/java/R enable options, I've added it to my list to investigate but I don't have much time and it's really something the maintainer should be doing. ARMv7 appears to have completed: http://koji.fedoraproject.org/koji/taskinfo?taskID=13973607 Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |