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.

Sign up for GitHub

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: arm v5 binary crashing on arm v8 #63487

Closed
cuonglm opened this issue Oct 10, 2023 · 2 comments
Closed

runtime: arm v5 binary crashing on arm v8 #63487

cuonglm opened this issue Oct 10, 2023 · 2 comments
Labels
arch-arm Issues solely affecting the 32-bit arm architecture. compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@cuonglm
Copy link
Member

cuonglm commented Oct 10, 2023 •
edited

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

$ go version
go version go1.21.2 linux/amd64

Does this issue reproduce with the latest release?

Yes.

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

go env Output
$ go env

What did you do?

Cross compiling an arm v5 binary, then running on an arm v8 host:

$ cat main.go 
package main

func main() {
	println("vim-go")
}
$ GOARCH=arm GOARM=5 go1.21.2 build main.go
$ file main
main: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, Go BuildID=xIqgFae_BjP2KRClZWF_/dP05AtKugNG8nUVF-all/SDPFN3Fk3yWWZoK5qVk2/iJH8EU4daO0u_Ug6a0gX, with debug_info, not stripped

What did you expect to see?

The binary run ok.

What did you see instead?

The binary crashes:

fatal error: out of memory allocating heap arena map

runtime stack:
runtime.throw({0x8ddec, 0x27})
	/home/cuonglm/sdk/go1.21.2/src/runtime/panic.go:1077 +0x4c fp=0xffc00db0 sp=0xffc00d9c pc=0x45748
runtime.(*mheap).sysAlloc(0xf5e30, 0x400000, 0xf5f3c, 0x1)
	/home/cuonglm/sdk/go1.21.2/src/runtime/malloc.go:741 +0x350 fp=0xffc00e00 sp=0xffc00db0 pc=0x19bf0
runtime.(*mheap).grow(0xf5e30, 0x1)
	/home/cuonglm/sdk/go1.21.2/src/runtime/mheap.go:1483 +0x84 fp=0xffc00e54 sp=0xffc00e00 pc=0x37b90
runtime.(*mheap).allocSpan(0xf5e30, 0x1, 0x0, 0x8)
	/home/cuonglm/sdk/go1.21.2/src/runtime/mheap.go:1250 +0x1d8 fp=0xffc00ed8 sp=0xffc00e54 pc=0x3725c
runtime.(*mheap).alloc.func1()
	/home/cuonglm/sdk/go1.21.2/src/runtime/mheap.go:968 +0x84 fp=0xffc00efc sp=0xffc00ed8 pc=0x36d14
runtime.(*mheap).alloc(0xf5e30, 0x1, 0x8)
	/home/cuonglm/sdk/go1.21.2/src/runtime/mheap.go:962 +0x58 fp=0xffc00f1c sp=0xffc00efc pc=0x36c70
runtime.(*mcentral).grow(0xf6380)
	/home/cuonglm/sdk/go1.21.2/src/runtime/mcentral.go:246 +0x64 fp=0xffc00f3c sp=0xffc00f1c pc=0x21ce0
runtime.(*mcentral).cacheSpan(0xf6380)
	/home/cuonglm/sdk/go1.21.2/src/runtime/mcentral.go:166 +0x114 fp=0xffc00f7c sp=0xffc00f3c pc=0x21854
runtime.(*mcache).refill(0xf76cb088, 0x8)
	/home/cuonglm/sdk/go1.21.2/src/runtime/mcache.go:182 +0x18c fp=0xffc00fac sp=0xffc00f7c pc=0x21050
runtime.(*mcache).nextFree(0xf76cb088, 0x8)
	/home/cuonglm/sdk/go1.21.2/src/runtime/malloc.go:925 +0x84 fp=0xffc00fd0 sp=0xffc00fac pc=0x1a168
runtime.mallocgc(0x20, 0x84068, 0x1)
	/home/cuonglm/sdk/go1.21.2/src/runtime/malloc.go:1112 +0x5bc fp=0xffc01008 sp=0xffc00fd0 pc=0x1a8dc
runtime.newobject(0x84068)
	/home/cuonglm/sdk/go1.21.2/src/runtime/malloc.go:1324 +0x2c fp=0xffc0101c sp=0xffc01008 pc=0x1af64
internal/cpu.doinit(...)
	/home/cuonglm/sdk/go1.21.2/src/internal/cpu/cpu_arm.go:22
internal/cpu.Initialize({0x0, 0x0})
	/home/cuonglm/sdk/go1.21.2/src/internal/cpu/cpu.go:125 +0x20 fp=0xffc0102c sp=0xffc0101c pc=0x11244
runtime.cpuinit(...)
	/home/cuonglm/sdk/go1.21.2/src/runtime/proc.go:639
runtime.schedinit()
	/home/cuonglm/sdk/go1.21.2/src/runtime/proc.go:729 +0xb4 fp=0xffc01050 sp=0xffc0102c pc=0x499ac
runtime.rt0_go()
	/home/cuonglm/sdk/go1.21.2/src/runtime/asm_arm.s:168 +0x7c fp=0xffc01090 sp=0xffc01050 pc=0x74a24

Cross compiling a C binary using gcc work just fine:

$ cat main.c 
#include<stdio.h>
int main()
{
        printf("Hello World!\n");
        return 0;
}
$ arm-linux-gnueabi-gcc main.c -o helloworld-arm -static
$ file helloworld-arm 
helloworld-arm: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, BuildID[sha1]=cc5d266be81ac7e6673e9336375af11dd425e9f9, for GNU/Linux 3.2.0, not stripped

The arm v8 host is Asus RT-AX68U:

$ cat /proc/cpuinfo
processor	: 0
cpu model	: ARM
BogoMIPS	: 100.00
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer	: 0x42
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0x100
CPU revision	: 0

processor	: 1
cpu model	: ARM
BogoMIPS	: 100.00
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer	: 0x42
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0x100
CPU revision	: 0
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Oct 10, 2023
@cuonglm cuonglm added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. arch-arm Issues solely affecting the 32-bit arm architecture. labels Oct 10, 2023
@cuonglm
Copy link
Member Author

cuonglm commented Oct 10, 2023

cc @golang/arm

@cuonglm
Copy link
Member Author

cuonglm commented Oct 10, 2023

Don't mind, this seems to be a false alarm because the device is on a weird state.

I rebooted the device and thing starts working.

@cuonglm cuonglm closed this as completed Oct 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
arch-arm Issues solely affecting the 32-bit arm architecture. compiler/runtime Issues related to the Go compiler and/or runtime. 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
2 participants
@cuonglm @gopherbot