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

Jump to bottom

runtime: hello world segfaults on broadcom 7439 chipset #23787

Closed
frepe360 opened this issue Feb 12, 2018 · 13 comments
Closed

runtime: hello world segfaults on broadcom 7439 chipset #23787

frepe360 opened this issue Feb 12, 2018 · 13 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@frepe360
Copy link

frepe360 commented Feb 12, 2018 •
edited by ALTree

What version of Go are you using (go version)?

go version go1.9.4 linux/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/frper/go"
GORACE=""
GOROOT="/home/frper/Downloads/go"
GOTOOLDIR="/home/frper/Downloads/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build833695989=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?

I built a hello world program and ran it on two different ARM7/linux hosts. It segfaults on one of them.

The program:

package main

import "fmt"

func main() {
     fmt.Println("hello world")
}

Build command:

GOARCH=arm ./go build ~/src/go/helloworld.go

What did you expect to see?

First host was a raspberry pi running linux:
pi@retropie:~ $ cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

On this host, the program runs find.

The second host was a broadcom 7439 chipset running linux kernel version 3.14.28.
cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 3 (v7l)
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x42
CPU architecture: 7
CPU variant : 0x0
CPU part : 0x00f
CPU revision : 3

On this host, the program segfaults. Here is a gdb backtrace:

Program received signal SIGSEGV, Segmentation fault.
0xffff0fc0 in ?? ()
(gdb) bt
#0 0xffff0fc0 in ?? ()
#1 0x00011d34 in runtime/internal/atomic.Cas () at /home/frper/Downloads/go/src/runtime/internal/atomic/sys_linux_arm.s:17
#2 0x00045b0c in runtime.check () at /home/frper/Downloads/go/src/runtime/runtime1.go:218
#3 0x0005c6a8 in runtime.rt0_go () at /home/frper/Downloads/go/src/runtime/asm_arm.s:51
#4 0x00000000 in ?? ()

I expect the program to not segfault.

What did you see instead?

The program segfaults.
@ALTree
Copy link
Member

ALTree commented Feb 12, 2018 •
edited

Can you try cross-compiling with the correct GOARM value?

 GOARCH=arm GOARM=7 go build ...

the doc says:

the appropriate GOARM value will be chosen if you compile the program from source on the target machine. In cross compilation situations, it is recommended that you always set an appropriate GOARM value along with GOARCH.

Stress on

In cross compilation situations, it is recommended that you always set an appropriate GOARM

@ALTree ALTree changed the title Hello world segfaults on broadcom 7439 chipset runtime: hello world segfaults on broadcom 7439 chipset Feb 12, 2018
@ALTree ALTree added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 12, 2018
@frepe360
Copy link
Author

frepe360 commented Feb 12, 2018 •
edited

I have done that, the result is the same.

I have tried GOARM=5, GOARM=6 and GOARM=7 and they all segfault with the same backtrace on broadcom 7439, and they all run fine on the raspberry pi.

@ALTree
Copy link
Member

ALTree commented Feb 12, 2018

Thanks for trying. Any chance you could test this with the 1.10 release candidate? https://godoc.org/golang.org/x/build/version/go1.10rc1

@frepe360
Copy link
Author

With go1.10rc1, it segfaults with an even shorter backtrace:

/tmp/nfs # ./helloworld-go10.10rc1-arm7 
Segmentation fault
/tmp/nfs # ./gdb helloworld-go10.10rc1-arm7 
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /tmp/nfs/helloworld-go10.10rc1-arm7...done.
(gdb) r
Starting program: /tmp/nfs/helloworld-go10.10rc1-arm7 

Program received signal SIGSEGV, Segmentation fault.
0xffff0fc0 in ?? ()
(gdb)

On the raspberry pi, it still works fine.

@ALTree
Copy link
Member

ALTree commented Feb 12, 2018

cc @aclements @cherrymui

@cherrymui
Copy link
Member

cherrymui commented Feb 12, 2018 •
edited

On Linux/ARM, we use the atomic operations provided by the kernel. 0xffff0fc0
is the kernel entry point (https://github.com/torvalds/linux/blob/master/arch/arm/kernel/entry-armv.S#L941). What version of the kernel are you running? Maybe the kernel you're running does not support this? (I don't know what config option controls this. I'll look it up.)

@cherrymui
Copy link
Member

Seems CONFIG_KUSER_HELPERS?

@frepe360
Copy link
Author

I am using linux kernel version 3.14.28. It seems to have the 0xffff0fc0 entry point in arch/arm/kernel/entry-armv.S:

__kuser_memory_barrier:                         @ 0xffff0fa0
	smp_dmb arm
        usr_ret lr

        kuser_pad __kuser_memory_barrier, 32

__kuser_cmpxchg:                                @ 0xffff0fc0

#if defined(CONFIG_NEEDS_SYSCALL_FOR_CMPXCHG)

        /*                                                                                                                                                                
         * Poor you.  No fast solution possible...                                                                                                                        
         * The kernel itself must perform the operation.

My kernel config does not have CONFIG_KUSER_HELPERS at all, "zcat config.gz |grep CONFIG_KUSER_HELPERS" returns nothing.

@frepe360
Copy link
Author

Sorry, obviously CONFIG_KUSER_HELPERS is there, but it does not seem to be enabled.

@cherrymui
Copy link
Member

@frepe360 yeah, I think CONFIG_KUSER_HELPERS is the reason. Would you be able to rebuild the kernel with this option enabled?

It might be better for Go to support machines without CONFIG_KUSER_HELPERS. I'll open a separate issue.

@frepe360
Copy link
Author

Yes, I will try this, thank you.

@cherrymui cherrymui mentioned this issue Feb 12, 2018
Closed
@frepe360
Copy link
Author

@cherrymui I can verify your assumption; I have now enabled CONFIG_KUSER_HELPERS=y and all of the binaries above now run as they should.

Thank you for your help.

@aclements
Copy link
Member

Glad that worked! Closing this issue and shifting further discussion of the general problem over to #23792.

@golang golang locked and limited conversation to collaborators Feb 12, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@frepe360 @aclements @ALTree @gopherbot @cherrymui