I'm playing with go v1.8 on an armv7 and found something odd. I can
compile, run, etc pure go programs, but when I try importing zeromq it
fails to run even this:
package main
import (
zmq "github.com/pebbe/zmq4"
"fmt"
)
func main() {
fmt.Println(zmq.Version())
}
And I get a stacktrace like so:
./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
>
I tried to debug it but it runs as without issue under GDB. I'm guessing it
does some virtualization? QEMU works too.
gdbserver :1000 zmq
> Process zmq created; pid = 742
> Listening on port 1000
> Remote debugging from host 10.0.0.36
> runtime: asks for:1048576-byte block (0 in use)
> 4 2 1
Child exited with status 0
strace shows it requesting an unexpectedly large amount of memory for the
bitmap:
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)
> write(2, "fatal error: ", 13fatal error: ) = 13
The first mmap looks right, this is the chunk size, but the second one for
the bitmap I would expect to be 16x smaller. Is this an issue with the ARM
target? Why would it only show up when linking zeromq? It looks like this
is the common path for the code and I assume the runtime functions are
correct so is there a configuration/porting detail that could cause this?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
