davecheney
commented
7 years ago This works for me when compiling your sample program natively on a raspberry pi. Have you tried building locally on your arm system? It's probably going to be simpler than maintaining a cross compilation environment.
On Tue, Apr 4, 2017 at 10:54 AM, Chris Johnson notifications@github.com wrote:
What version of Go are you using (go version)?
1.8 linux/amd64
go env ($TOOLCHAIN and $SYSROOT are for cross compile) GOHOSTARCH="amd64" GOHOSTOS="linux" GOOS="linux" CGO_ENABLED=1 C_INCLUDE_PATH=$SYSROOT/usr/include/ LIBRARY_PATH=$SYSROOT/usr/lib CC=$TOOLCHAIN PKG_CONFIG_PATH=$SYSROOT/usr/lib/pkgconfig/ GOARCH=arm GOARM=7
I'm using go v1.8 to cross compile to an armv7 target and everything works until I import zeromq, and then not even this works:
package main
import ( zmq "github.com/pebbe/zmq4" "fmt" )
func main() { fmt.Println(zmq.Version()) }
Running it on the target gives the following:
./zmq fatal error: runtime: out of memory
runtime stack: runtime.throw(0xc8d3d, 0x16) /usr/lib/go/src/runtime/panic.go:596 +0x70 fp=0x7eb018a0 sp=0x7eb01894 runtime.sysMap(0x6d752000, 0x74d4000, 0x1, 0x146b60) /usr/lib/go/src/runtime/mem_linux.go:227 +0xb0 fp=0x7eb018c4 sp=0x7eb018a0 runtime.(mheap).mapBits(0x139d58, 0x74d26000) /usr/lib/go/src/runtime/mbitmap.go:159 +0x94 fp=0x7eb018dc sp=0x7eb018c4 runtime.(mheap).sysAlloc(0x139d58, 0x100000, 0x30414) /usr/lib/go/src/runtime/malloc.go:428 +0x2dc fp=0x7eb0191c sp=0x7eb018dc runtime.(mheap).grow(0x139d58, 0x8, 0x0) /usr/lib/go/src/runtime/mheap.go:774 +0xd0 fp=0x7eb0194c sp=0x7eb0191c runtime.(mheap).allocSpanLocked(0x139d58, 0x1, 0x0) /usr/lib/go/src/runtime/mheap.go:678 +0x468 fp=0x7eb0196c sp=0x7eb0194c runtime.(mheap).alloc_m(0x139d58, 0x1, 0x10, 0x0, 0x0) /usr/lib/go/src/runtime/mheap.go:562 +0xdc fp=0x7eb019a4 sp=0x7eb0196c runtime.(mheap).alloc.func1() /usr/lib/go/src/runtime/mheap.go:627 +0x3c fp=0x7eb019c0 sp=0x7eb019a4 runtime.systemstack(0x7eb019d4) /usr/lib/go/src/runtime/asm_arm.s:278 +0xa8 fp=0x7eb019c4 sp=0x7eb019c0 runtime.(mheap).alloc(0x139d58, 0x1, 0x10, 0x100, 0x1) /usr/lib/go/src/runtime/mheap.go:628 +0x60 fp=0x7eb019ec sp=0x7eb019c4 runtime.(mcentral).grow(0x13ab98, 0x0) /usr/lib/go/src/runtime/mcentral.go:212 +0x84 fp=0x7eb01a18 sp=0x7eb019ec runtime.(mcentral).cacheSpan(0x13ab98, 0x146b68) /usr/lib/go/src/runtime/mcentral.go:93 +0x104 fp=0x7eb01a5c sp=0x7eb01a18 runtime.(mcache).refill(0x649e5000, 0x10, 0x146b68) /usr/lib/go/src/runtime/mcache.go:122 +0x7c fp=0x7eb01a70 sp=0x7eb01a5c runtime.(mcache).nextFree.func1() /usr/lib/go/src/runtime/malloc.go:525 +0x24 fp=0x7eb01a80 sp=0x7eb01a70 runtime.systemstack(0x7eb01aa4) /usr/lib/go/src/runtime/asm_arm.s:278 +0xa8 fp=0x7eb01a84 sp=0x7eb01a80 runtime.(mcache).nextFree(0x649e5000, 0x649e5010, 0x7eb01acc, 0x1ebd4, 0x21c40) /usr/lib/go/src/runtime/malloc.go:526 +0x9c fp=0x7eb01ab0 sp=0x7eb01a84 runtime.mallocgc(0xf0, 0xc2548, 0x1, 0x64a26001) /usr/lib/go/src/runtime/malloc.go:678 +0x8c0 fp=0x7eb01b08 sp=0x7eb01ab0 runtime.newobject(0xc2548, 0x1384a0) /usr/lib/go/src/runtime/malloc.go:807 +0x2c fp=0x7eb01b1c sp=0x7eb01b08 runtime.malg(0x8000, 0x2710) /usr/lib/go/src/runtime/proc.go:2821 +0x1c fp=0x7eb01b38 sp=0x7eb01b1c runtime.mpreinit(0x138730) /usr/lib/go/src/runtime/os_linux.go:302 +0x1c fp=0x7eb01b44 sp=0x7eb01b38 runtime.mcommoninit(0x138730) /usr/lib/go/src/runtime/proc.go:540 +0x94 fp=0x7eb01b5c sp=0x7eb01b44 runtime.schedinit() /usr/lib/go/src/runtime/proc.go:476 +0x40 fp=0x7eb01b78 sp=0x7eb01b5c runtime.rt0_go(0x7eb01d14, 0x76ee4000, 0x7eb01d14, 0x1, 0x5cd10, 0x7eb01c58, 0x76f8e000, 0xcef6f281, 0xc6a63e08, 0x128, ...) /usr/lib/go/src/runtime/asm_arm.s:61 +0x84 fp=0x7eb01bb8 sp=0x7eb01b78
Tracing shows the offending mmap:
mmap2(0x74c54000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x74c54000 mmap2(0x6d77e000, 122511360, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
The first one is right, that's the chunk size, but the second is where it allocates the bitmap. It should be probably 16x smaller.
I tried debugging but it works under GDB. Maybe GDB does some virtualization?
gdbserver :1000 zmq Process zmq created; pid = 817 Listening on port 1000 Remote debugging from host 10.0.0.36 4 2 1
Child exited with status 0
So far, all pure go programs I've tested work as well.
Why does importing zeromq cause it to fail? Is there a bug in the arm port of go?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/19831, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAcA-ghneoorfxtrG1WQlPURRCd6SrRks5rsZThgaJpZM4MyRGu .
plasticchris
bradfitz
aclements
gopherbot
go version 1.8 linux/amd64
go env ($TOOLCHAIN and $SYSROOT are for cross compile) GOHOSTARCH="amd64" GOHOSTOS="linux" GOOS="linux" CGO_ENABLED=1 C_INCLUDE_PATH=$SYSROOT/usr/include/ LIBRARY_PATH=$SYSROOT/usr/lib CC=$TOOLCHAIN PKG_CONFIG_PATH=$SYSROOT/usr/lib/pkgconfig/ GOARCH=arm GOARM=7
I'm using go v1.8 to cross compile to an armv7 target and everything works until I import zeromq, and then not even this works:
Running it on the target gives the following:
Tracing shows the offending mmap:
The first one is right, that's the chunk size, but the second is where it allocates the bitmap. It should be probably 16x smaller.
I tried debugging but it works under GDB. Maybe GDB does some virtualization?
So far, all pure go programs I've tested work as well.
Why does importing zeromq cause it to fail? Is there a bug in the arm port of go?