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

runtime: hello world segfaults on broadcom 7439 chipset #23787

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

Comments

Projects
None yet
5 participants
@frepe360
Copy link

commented Feb 12, 2018

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

This comment has been minimized.

Copy link
Member

commented Feb 12, 2018

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

@frepe360

This comment has been minimized.

Copy link
Author

commented Feb 12, 2018

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Author

commented Feb 12, 2018

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

This comment has been minimized.

Copy link
Member

commented Feb 12, 2018

@cherrymui

This comment has been minimized.

Copy link
Contributor

commented Feb 12, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Feb 12, 2018

Seems CONFIG_KUSER_HELPERS?

@frepe360

This comment has been minimized.

Copy link
Author

commented Feb 12, 2018

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

This comment has been minimized.

Copy link
Author

commented Feb 12, 2018

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

@cherrymui

This comment has been minimized.

Copy link
Contributor

commented Feb 12, 2018

@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

This comment has been minimized.

Copy link
Author

commented Feb 12, 2018

Yes, I will try this, thank you.

@frepe360

This comment has been minimized.

Copy link
Author

commented Feb 12, 2018

@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

This comment has been minimized.

Copy link
Member

commented Feb 12, 2018

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

@aclements aclements closed this Feb 12, 2018

@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.
You can’t perform that action at this time.