added here as well: https://github.com/golang/go/issues/19831
On Monday, April 3, 2017 at 1:57:57 PM UTC-7, Chris Johnson wrote:
>
> 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.
