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: "fatal error: runtime: name offset out of range" on Android 6.0.1 arm64-v8a #38838

x0b opened this issue May 3, 2020 · 20 comments
arch-arm64 FrozenDueToAge NeedsInvestigation OS-Android


Copy link

@x0b x0b commented May 3, 2020

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

$ go version
go version go1.14 windows/amd64

Does this issue reproduce with the latest release?

Not sure

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

go env Output
$ go env

set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\User\AppData\Local\go-build
set GOENV=C:\Users\User\AppData\Roaming\go\env
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\User\go
set GOPROXY=,direct
set GOROOT=C:\sdev\Go
set GOTOOLDIR=C:\sdev\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\User\AppData\Local\Temp\go-build666510838=/tmp/go-build -gno-record-gcc-switches

What did you do?

Cross-Compiled rclone for Android and ran it there inside of an app (original issue: x0b/rcx#58). About 2% of arm64-v8a devices seem to be affected, no complaints from the rest.

Build Commands/Env:

set CC=android-sdk\ndk-bundle\toolchains\llvm\prebuilt\windows-x86_64\bin\aarch64-linux-android21-clang.cmd
set CC_FOR_TARGET=android-sdk\ndk-bundle\toolchains\llvm\prebuilt\windows-x86_64\bin\aarch64-linux-android21-clang.cmd
set GOOS=android
set GOARCH=arm64

go build -tags linux -o ../app/lib/arm64-v8a/

Run Env

Chipset: Qualcomm MSM8956 Snapdragon 650
Android: 6.0.1 / API 23 / CM 13.0-20171215-UNOFFICIAL-kenzo
Kernel: Linux version 3.10.108-SecuRadon-v6.1.1 (gismo@zeus) (gcc version 4.9.x-google 20140827 (prerelease) (GCC) ) #1 SMP PREEMPT Fri Dec 15 23:40:05 EET 2017

Run command

rclone -vvv listremotes

What did you expect to see?

Normal program operation.

What did you see instead?

fatal error: runtime: name offset out of range
2020-05-02 14:25:06 - runtime: nameOff 0x7d987be0 out of range 0x557d85a9c0 - 0x557dcf37c0
fatal error: runtime: name offset out of range

goroutine 1 [running, locked to thread]:
runtime.throw(0x557d533189, 0x21)
C:/sdev/Go/src/runtime/panic.go:1112 +0x4c fp=0x40000c99f0 sp=0x40000c99c0 pc=0x557c983d04
runtime.resolveNameOff(0x557da531a0, 0x7d987be0, 0x557d8634c8)
C:/sdev/Go/src/runtime/type.go:195 +0x290 fp=0x40000c9a60 sp=0x40000c99f0 pc=0x557c9ab888
reflect.resolveNameOff(0x557da531a0, 0x557d987be0, 0x557d8634c8)
C:/sdev/Go/src/runtime/runtime1.go:482 +0x28 fp=0x40000c9a90 sp=0x40000c9a60 pc=0x557c9955f0
reflect.implements(0x557da531a0, 0x557d9ffe40, 0x0)
C:/sdev/Go/src/reflect/type.go:1520 +0x3bc fp=0x40000c9be0 sp=0x40000c9a90 pc=0x557c9e1914
reflect.(*rtype).Implements(0x557d9ffe40, 0x557dcc7ca0, 0x557da531a0, 0x557ce18900)
C:/sdev/Go/src/reflect/type.go:1437 +0x60 fp=0x40000c9c10 sp=0x40000c9be0 pc=0x557c9e1348
encoding/gob.implementsInterface(0x557dcc7ca0, 0x557dbae2c0, 0x557dcc7ca0, 0x557da531a0, 0x0)
C:/sdev/Go/src/encoding/gob/type.go:142 +0x128 fp=0x40000c9c60 sp=0x40000c9c10 pc=0x557ce18f00
encoding/gob.validUserType(0x557dcc7ca0, 0x557dbae2c0, 0x557e701640, 0x557c95c848, 0x40002092c0)
C:/sdev/Go/src/encoding/gob/type.go:90 +0x2f0 fp=0x40000c9cf0 sp=0x40000c9c60 pc=0x557ce18c18
encoding/gob.userType(0x557dcc7ca0, 0x557dbae2c0, 0x557dbae2c0)
C:/sdev/Go/src/encoding/gob/type.go:152 +0x28 fp=0x40000c9d40 sp=0x40000c9cf0 pc=0x557ce18fb0
encoding/gob.mustGetTypeInfo(0x557dcc7ca0, 0x557dbae2c0, 0x557dcc7ca0)
C:/sdev/Go/src/encoding/gob/type.go:766 +0x28 fp=0x40000c9d90 sp=0x40000c9d40 pc=0x557ce1c6a0
C:/sdev/Go/src/encoding/gob/type.go:259 +0x1bcc fp=0x40000c9e30 sp=0x40000c9d90 pc=0x557ce1fce4
C:/sdev/Go/src/runtime/proc.go:5414 +0x94 fp=0x40000c9e70 sp=0x40000c9e30 pc=0x557c99314c
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9eb0 sp=0x40000c9e70 pc=0x557c993108
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9ef0 sp=0x40000c9eb0 pc=0x557c993108
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9f30 sp=0x40000c9ef0 pc=0x557c993108
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9f70 sp=0x40000c9f30 pc=0x557c993108
C:/sdev/Go/src/runtime/proc.go:190 +0x1d0 fp=0x40000c9fd0 sp=0x40000c9f70 pc=0x557c986a88
C:/sdev/Go/src/runtime/asm_arm64.s:1148 +0x4 fp=0x40000c9fd0 sp=0x40000c9fd0 pc=0x557c9b477c

fatal error: runtime: name offset out of range
2020-05-02 14:25:06 - runtime: nameOff 0x64e88be0 out of range 0x5564d5b9c0 - 0x55651f47c0
fatal error: runtime: name offset out of range

goroutine 1 [running, locked to thread]:
runtime.throw(0x5564a34189, 0x21)
C:/sdev/Go/src/runtime/panic.go:1112 +0x4c fp=0x400014f9f0 sp=0x400014f9c0 pc=0x5563e84d04
runtime.resolveNameOff(0x5564f541a0, 0x64e88be0, 0x5564d644c8)
C:/sdev/Go/src/runtime/type.go:195 +0x290 fp=0x400014fa60 sp=0x400014f9f0 pc=0x5563eac888
reflect.resolveNameOff(0x5564f541a0, 0x5564e88be0, 0x5564d644c8)
C:/sdev/Go/src/runtime/runtime1.go:482 +0x28 fp=0x400014fa90 sp=0x400014fa60 pc=0x5563e965f0
reflect.implements(0x5564f541a0, 0x5564f00e40, 0x0)
C:/sdev/Go/src/reflect/type.go:1520 +0x3bc fp=0x400014fbe0 sp=0x400014fa90 pc=0x5563ee2914
reflect.(*rtype).Implements(0x5564f00e40, 0x55651c8ca0, 0x5564f541a0, 0x5564319900)
C:/sdev/Go/src/reflect/type.go:1437 +0x60 fp=0x400014fc10 sp=0x400014fbe0 pc=0x5563ee2348
encoding/gob.implementsInterface(0x55651c8ca0, 0x55650af2c0, 0x55651c8ca0, 0x5564f541a0, 0x0)
C:/sdev/Go/src/encoding/gob/type.go:142 +0x128 fp=0x400014fc60 sp=0x400014fc10 pc=0x5564319f00
encoding/gob.validUserType(0x55651c8ca0, 0x55650af2c0, 0x5565c02640, 0x5563e5d848, 0x40000912c0)
C:/sdev/Go/src/encoding/gob/type.go:90 +0x2f0 fp=0x400014fcf0 sp=0x400014fc60 pc=0x5564319c18
encoding/gob.userType(0x55651c8ca0, 0x55650af2c0, 0x55650af2c0)
C:/sdev/Go/src/encoding/gob/type.go:152 +0x28 fp=0x400014fd40 sp=0x400014fcf0 pc=0x5564319fb0
encoding/gob.mustGetTypeInfo(0x55651c8ca0, 0x55650af2c0, 0x55651c8ca0)
C:/sdev/Go/src/encoding/gob/type.go:766 +0x28 fp=0x400014fd90 sp=0x400014fd40 pc=0x556431d6a0
C:/sdev/Go/src/encoding/gob/type.go:259 +0x1bcc fp=0x400014fe30 sp=0x400014fd90 pc=0x5564320ce4
C:/sdev/Go/src/runtime/proc.go:5414 +0x94 fp=0x400014fe70 sp=0x400014fe30 pc=0x5563e9414c
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x400014feb0 sp=0x400014fe70 pc=0x5563e94108
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x400014fef0 sp=0x400014feb0 pc=0x5563e94108
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x400014ff30 sp=0x400014fef0 pc=0x5563e94108
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x400014ff70 sp=0x400014ff30 pc=0x5563e94108
C:/sdev/Go/src/runtime/proc.go:190 +0x1d0 fp=0x400014ffd0 sp=0x400014ff70 pc=0x5563e87a88
C:/sdev/Go/src/runtime/asm_arm64.s:1148 +0x4 fp=0x400014ffd0 sp=0x400014ffd0 pc=0x5563eb577c

fatal error: runtime: name offset out of range
2020-05-02 14:27:31 - runtime: nameOff 0x7fa05be0 out of range 0x557f8d89c0 - 0x557fd717c0
fatal error: runtime: name offset out of range

goroutine 1 [running, locked to thread]:
runtime.throw(0x557f5b1189, 0x21)
C:/sdev/Go/src/runtime/panic.go:1112 +0x4c fp=0x40000c99f0 sp=0x40000c99c0 pc=0x557ea01d04
runtime.resolveNameOff(0x557fad11a0, 0x7fa05be0, 0x557f8e14c8)
C:/sdev/Go/src/runtime/type.go:195 +0x290 fp=0x40000c9a60 sp=0x40000c99f0 pc=0x557ea29888
reflect.resolveNameOff(0x557fad11a0, 0x557fa05be0, 0x557f8e14c8)
C:/sdev/Go/src/runtime/runtime1.go:482 +0x28 fp=0x40000c9a90 sp=0x40000c9a60 pc=0x557ea135f0
reflect.implements(0x557fad11a0, 0x557fa7de40, 0x0)
C:/sdev/Go/src/reflect/type.go:1520 +0x3bc fp=0x40000c9be0 sp=0x40000c9a90 pc=0x557ea5f914
reflect.(*rtype).Implements(0x557fa7de40, 0x557fd45ca0, 0x557fad11a0, 0x557ee96900)
C:/sdev/Go/src/reflect/type.go:1437 +0x60 fp=0x40000c9c10 sp=0x40000c9be0 pc=0x557ea5f348
encoding/gob.implementsInterface(0x557fd45ca0, 0x557fc2c2c0, 0x557fd45ca0, 0x557fad11a0, 0x0)
C:/sdev/Go/src/encoding/gob/type.go:142 +0x128 fp=0x40000c9c60 sp=0x40000c9c10 pc=0x557ee96f00
encoding/gob.validUserType(0x557fd45ca0, 0x557fc2c2c0, 0x558077f640, 0x557e9da848, 0x4000285300)
C:/sdev/Go/src/encoding/gob/type.go:90 +0x2f0 fp=0x40000c9cf0 sp=0x40000c9c60 pc=0x557ee96c18
encoding/gob.userType(0x557fd45ca0, 0x557fc2c2c0, 0x557fc2c2c0)
C:/sdev/Go/src/encoding/gob/type.go:152 +0x28 fp=0x40000c9d40 sp=0x40000c9cf0 pc=0x557ee96fb0
encoding/gob.mustGetTypeInfo(0x557fd45ca0, 0x557fc2c2c0, 0x557fd45ca0)
C:/sdev/Go/src/encoding/gob/type.go:766 +0x28 fp=0x40000c9d90 sp=0x40000c9d40 pc=0x557ee9a6a0
C:/sdev/Go/src/encoding/gob/type.go:259 +0x1bcc fp=0x40000c9e30 sp=0x40000c9d90 pc=0x557ee9dce4
C:/sdev/Go/src/runtime/proc.go:5414 +0x94 fp=0x40000c9e70 sp=0x40000c9e30 pc=0x557ea1114c
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9eb0 sp=0x40000c9e70 pc=0x557ea11108
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9ef0 sp=0x40000c9eb0 pc=0x557ea11108
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9f30 sp=0x40000c9ef0 pc=0x557ea11108
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9f70 sp=0x40000c9f30 pc=0x557ea11108
C:/sdev/Go/src/runtime/proc.go:190 +0x1d0 fp=0x40000c9fd0 sp=0x40000c9f70 pc=0x557ea04a88
C:/sdev/Go/src/runtime/asm_arm64.s:1148 +0x4 fp=0x40000c9fd0 sp=0x40000c9fd0 pc=0x557ea3277c

fatal error: fault
2020-05-02 14:27:31 - unexpected fault address 0x55252305a1
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1 addr=0x55252305a1 pc=0x5591a0899c]

goroutine 1 [running, locked to thread]:
runtime.throw(0x55925295ff, 0x5)
C:/sdev/Go/src/runtime/panic.go:1112 +0x4c fp=0x40000c9a50 sp=0x40000c9a20 pc=0x55919aad04
C:/sdev/Go/src/runtime/signal_unix.go:694 +0x37c fp=0x40000c9a80 sp=0x40000c9a50 pc=0x55919c1a14
reflect.implements(0x5592a7a1a0, 0x5592a26e40, 0x0)
C:/sdev/Go/src/reflect/type.go:1523 +0x444 fp=0x40000c9be0 sp=0x40000c9a90 pc=0x5591a0899c
reflect.(*rtype).Implements(0x5592a26e40, 0x5592ceeca0, 0x5592a7a1a0, 0x5591e3f900)
C:/sdev/Go/src/reflect/type.go:1437 +0x60 fp=0x40000c9c10 sp=0x40000c9be0 pc=0x5591a08348
encoding/gob.implementsInterface(0x5592ceeca0, 0x5592bd52c0, 0x5592ceeca0, 0x5592a7a1a0, 0x0)
C:/sdev/Go/src/encoding/gob/type.go:142 +0x128 fp=0x40000c9c60 sp=0x40000c9c10 pc=0x5591e3ff00
encoding/gob.validUserType(0x5592ceeca0, 0x5592bd52c0, 0x5593728640, 0x5591983848, 0x4000091780)
C:/sdev/Go/src/encoding/gob/type.go:90 +0x2f0 fp=0x40000c9cf0 sp=0x40000c9c60 pc=0x5591e3fc18
encoding/gob.userType(0x5592ceeca0, 0x5592bd52c0, 0x5592bd52c0)
C:/sdev/Go/src/encoding/gob/type.go:152 +0x28 fp=0x40000c9d40 sp=0x40000c9cf0 pc=0x5591e3ffb0
encoding/gob.mustGetTypeInfo(0x5592ceeca0, 0x5592bd52c0, 0x5592ceeca0)
C:/sdev/Go/src/encoding/gob/type.go:766 +0x28 fp=0x40000c9d90 sp=0x40000c9d40 pc=0x5591e436a0
C:/sdev/Go/src/encoding/gob/type.go:259 +0x1bcc fp=0x40000c9e30 sp=0x40000c9d90 pc=0x5591e46ce4
C:/sdev/Go/src/runtime/proc.go:5414 +0x94 fp=0x40000c9e70 sp=0x40000c9e30 pc=0x55919ba14c
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9eb0 sp=0x40000c9e70 pc=0x55919ba108
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9ef0 sp=0x40000c9eb0 pc=0x55919ba108
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9f30 sp=0x40000c9ef0 pc=0x55919ba108
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9f70 sp=0x40000c9f30 pc=0x55919ba108
C:/sdev/Go/src/runtime/proc.go:190 +0x1d0 fp=0x40000c9fd0 sp=0x40000c9f70 pc=0x55919ada88
C:/sdev/Go/src/runtime/asm_arm64.s:1148 +0x4 fp=0x40000c9fd0 sp=0x40000c9fd0 pc=0x55919db77c

fatal error: runtime: name offset out of range
2020-05-02 14:27:32 - runtime: nameOff 0x7c3d8be0 out of range 0x557c2ab9c0 - 0x557c7447c0
fatal error: runtime: name offset out of range

goroutine 1 [running, locked to thread]:
runtime.throw(0x557bf84189, 0x21)
C:/sdev/Go/src/runtime/panic.go:1112 +0x4c fp=0x40000c99f0 sp=0x40000c99c0 pc=0x557b3d4d04
runtime.resolveNameOff(0x557c4a41a0, 0x7c3d8be0, 0x557c2b44c8)
C:/sdev/Go/src/runtime/type.go:195 +0x290 fp=0x40000c9a60 sp=0x40000c99f0 pc=0x557b3fc888
reflect.resolveNameOff(0x557c4a41a0, 0x557c3d8be0, 0x557c2b44c8)
C:/sdev/Go/src/runtime/runtime1.go:482 +0x28 fp=0x40000c9a90 sp=0x40000c9a60 pc=0x557b3e65f0
reflect.implements(0x557c4a41a0, 0x557c450e40, 0x0)
C:/sdev/Go/src/reflect/type.go:1520 +0x3bc fp=0x40000c9be0 sp=0x40000c9a90 pc=0x557b432914
reflect.(*rtype).Implements(0x557c450e40, 0x557c718ca0, 0x557c4a41a0, 0x557b869900)
C:/sdev/Go/src/reflect/type.go:1437 +0x60 fp=0x40000c9c10 sp=0x40000c9be0 pc=0x557b432348
encoding/gob.implementsInterface(0x557c718ca0, 0x557c5ff2c0, 0x557c718ca0, 0x557c4a41a0, 0x0)
C:/sdev/Go/src/encoding/gob/type.go:142 +0x128 fp=0x40000c9c60 sp=0x40000c9c10 pc=0x557b869f00
encoding/gob.validUserType(0x557c718ca0, 0x557c5ff2c0, 0x557d152640, 0x557b3ad848, 0x40001a7300)
C:/sdev/Go/src/encoding/gob/type.go:90 +0x2f0 fp=0x40000c9cf0 sp=0x40000c9c60 pc=0x557b869c18
encoding/gob.userType(0x557c718ca0, 0x557c5ff2c0, 0x557c5ff2c0)
C:/sdev/Go/src/encoding/gob/type.go:152 +0x28 fp=0x40000c9d40 sp=0x40000c9cf0 pc=0x557b869fb0
encoding/gob.mustGetTypeInfo(0x557c718ca0, 0x557c5ff2c0, 0x557c718ca0)
C:/sdev/Go/src/encoding/gob/type.go:766 +0x28 fp=0x40000c9d90 sp=0x40000c9d40 pc=0x557b86d6a0
C:/sdev/Go/src/encoding/gob/type.go:259 +0x1bcc fp=0x40000c9e30 sp=0x40000c9d90 pc=0x557b870ce4
C:/sdev/Go/src/runtime/proc.go:5414 +0x94 fp=0x40000c9e70 sp=0x40000c9e30 pc=0x557b3e414c
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9eb0 sp=0x40000c9e70 pc=0x557b3e4108
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9ef0 sp=0x40000c9eb0 pc=0x557b3e4108
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9f30 sp=0x40000c9ef0 pc=0x557b3e4108
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9f70 sp=0x40000c9f30 pc=0x557b3e4108
C:/sdev/Go/src/runtime/proc.go:190 +0x1d0 fp=0x40000c9fd0 sp=0x40000c9f70 pc=0x557b3d7a88
C:/sdev/Go/src/runtime/asm_arm64.s:1148 +0x4 fp=0x40000c9fd0 sp=0x40000c9fd0 pc=0x557b40577c

fatal error: runtime: name offset out of range
2020-05-02 14:27:32 - runtime: nameOff 0x65f18be0 out of range 0x5565deb9c0 - 0x55662847c0
fatal error: runtime: name offset out of range

goroutine 1 [running, locked to thread]:
runtime.throw(0x5565ac4189, 0x21)
C:/sdev/Go/src/runtime/panic.go:1112 +0x4c fp=0x40000c99f0 sp=0x40000c99c0 pc=0x5564f14d04
runtime.resolveNameOff(0x5565fe41a0, 0x65f18be0, 0x5565df44c8)
C:/sdev/Go/src/runtime/type.go:195 +0x290 fp=0x40000c9a60 sp=0x40000c99f0 pc=0x5564f3c888
reflect.resolveNameOff(0x5565fe41a0, 0x5565f18be0, 0x5565df44c8)
C:/sdev/Go/src/runtime/runtime1.go:482 +0x28 fp=0x40000c9a90 sp=0x40000c9a60 pc=0x5564f265f0
reflect.implements(0x5565fe41a0, 0x5565f90e40, 0x0)
C:/sdev/Go/src/reflect/type.go:1520 +0x3bc fp=0x40000c9be0 sp=0x40000c9a90 pc=0x5564f72914
reflect.(*rtype).Implements(0x5565f90e40, 0x5566258ca0, 0x5565fe41a0, 0x55653a9900)
C:/sdev/Go/src/reflect/type.go:1437 +0x60 fp=0x40000c9c10 sp=0x40000c9be0 pc=0x5564f72348
encoding/gob.implementsInterface(0x5566258ca0, 0x556613f2c0, 0x5566258ca0, 0x5565fe41a0, 0x0)
C:/sdev/Go/src/encoding/gob/type.go:142 +0x128 fp=0x40000c9c60 sp=0x40000c9c10 pc=0x55653a9f00
encoding/gob.validUserType(0x5566258ca0, 0x556613f2c0, 0x5566c92640, 0x5564eed848, 0x400020cd00)
C:/sdev/Go/src/encoding/gob/type.go:90 +0x2f0 fp=0x40000c9cf0 sp=0x40000c9c60 pc=0x55653a9c18
encoding/gob.userType(0x5566258ca0, 0x556613f2c0, 0x556613f2c0)
C:/sdev/Go/src/encoding/gob/type.go:152 +0x28 fp=0x40000c9d40 sp=0x40000c9cf0 pc=0x55653a9fb0
encoding/gob.mustGetTypeInfo(0x5566258ca0, 0x556613f2c0, 0x5566258ca0)
C:/sdev/Go/src/encoding/gob/type.go:766 +0x28 fp=0x40000c9d90 sp=0x40000c9d40 pc=0x55653ad6a0
C:/sdev/Go/src/encoding/gob/type.go:259 +0x1bcc fp=0x40000c9e30 sp=0x40000c9d90 pc=0x55653b0ce4
C:/sdev/Go/src/runtime/proc.go:5414 +0x94 fp=0x40000c9e70 sp=0x40000c9e30 pc=0x5564f2414c
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9eb0 sp=0x40000c9e70 pc=0x5564f24108
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9ef0 sp=0x40000c9eb0 pc=0x5564f24108
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9f30 sp=0x40000c9ef0 pc=0x5564f24108
C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9f70 sp=0x40000c9f30 pc=0x5564f24108
C:/sdev/Go/src/runtime/proc.go:190 +0x1d0 fp=0x40000c9fd0 sp=0x40000c9f70 pc=0x5564f17a88
C:/sdev/Go/src/runtime/asm_arm64.s:1148 +0x4 fp=0x40000c9fd0 sp=0x40000c9fd0 pc=0x5564f4577c

@dmitshur dmitshur added mobile arch-arm64 OS-Android labels May 8, 2020
Copy link

@dmitshur dmitshur commented May 8, 2020

Thanks for reporting. Is it possible to reproduce the problem with a smaller snippet?

/cc @hyangah @hajimehoshi

@dmitshur dmitshur added this to the Backlog milestone May 8, 2020
@dmitshur dmitshur added the NeedsInvestigation label May 8, 2020
@dmitshur dmitshur changed the title fatal error: runtime: name offset out of range / fatal error: fault on Android 6.0.1 arm64-v8a runtime: "fatal error: runtime: name offset out of range" on Android 6.0.1 arm64-v8a May 8, 2020
Copy link
Contributor Author

@x0b x0b commented May 10, 2020

Possibly, but I'm neither a go programmer, nor do I actually have a device where the error is reproducible (edit: But I do have a tech savvy end user, who can execute on-device tests)

However, we managed to confirm that this is a regression somewhere between 1.13.4 and 1.14:

golang rclone 1.50.2 rclone 1.51.0
1.13.4 OK OK
1.14 - nameOff
1.14.2 - nameOff

@ncw Do you have a clue where it fails? This would probably help to create a minimum reproducible snippet. We are executing rclone version.

go 1.13.4 (rclone 1.51.0, OK)
2020/05/10 12:00:51 ERROR : Couldn't find home directory or read HOME or XDG_CONFIG_HOME environment variables.
2020/05/10 12:00:51 ERROR : Defaulting to storing config in current directory.
2020/05/10 12:00:51 ERROR : Use --config flag to workaround.
2020/05/10 12:00:51 ERROR : Error was: exec: "getent": executable file not found in $PATH
rclone v1.51.0
- os/arch: android/arm64
- go version: go1.13.4
go 1.14.2 (rclone 1.51.0, nameOff)
2020/05/10 12:02:43 %!s(fs.LogLevel=3     ): Couldn't find home directory or read HOME or XDG_CONFIG_HOME environment variables.
2020/05/10 12:02:43 %!s(fs.LogLevel=3     ): Defaulting to storing config in current directory.
2020/05/10 12:02:43 %!s(fs.LogLevel=3     ): Use --config flag to workaround.
2020/05/10 12:02:43 %!s(fs.LogLevel=3     ): Error was: exec: "getent": executable file not found in $PATH
runtime: nameOff 0x57fb1cc0 out of range 0x5557e84a80 - 0x555831d640
fatal error: runtime: name offset out of range
goroutine 1 [running, locked to thread]:
runtime.throw(0x5557b5cb0e, 0x21)
	C:/sdev/Go/src/runtime/panic.go:1116 +0x4c fp=0x40000c99f0 sp=0x40000c99c0 pc=0x5556fad564
runtime.resolveNameOff(0x555807d280, 0x57fb1cc0, 0x5557e8d588)
	C:/sdev/Go/src/runtime/type.go:195 +0x290 fp=0x40000c9a60 sp=0x40000c99f0 pc=0x5556fd5148
reflect.resolveNameOff(0x555807d280, 0x5557fb1cc0, 0x5557e8d588)
	C:/sdev/Go/src/runtime/runtime1.go:482 +0x28 fp=0x40000c9a90 sp=0x40000c9a60 pc=0x5556fbeee0
reflect.implements(0x555807d280, 0x5558029f20, 0x0)
	C:/sdev/Go/src/reflect/type.go:1520 +0x3bc fp=0x40000c9be0 sp=0x40000c9a90 pc=0x555700b1d4
reflect.(*rtype).Implements(0x5558029f20, 0x55582f1b20, 0x555807d280, 0x5557442300)
	C:/sdev/Go/src/reflect/type.go:1437 +0x60 fp=0x40000c9c10 sp=0x40000c9be0 pc=0x555700ac08
encoding/gob.implementsInterface(0x55582f1b20, 0x55581d83a0, 0x55582f1b20, 0x555807d280, 0x0)
	C:/sdev/Go/src/encoding/gob/type.go:142 +0x128 fp=0x40000c9c60 sp=0x40000c9c10 pc=0x5557442890
encoding/gob.validUserType(0x55582f1b20, 0x55581d83a0, 0x5558d2b680, 0x5556f86038, 0x400007f7c0)
	C:/sdev/Go/src/encoding/gob/type.go:90 +0x2f0 fp=0x40000c9cf0 sp=0x40000c9c60 pc=0x55574425a8
encoding/gob.userType(0x55582f1b20, 0x55581d83a0, 0x55581d83a0)
	C:/sdev/Go/src/encoding/gob/type.go:152 +0x28 fp=0x40000c9d40 sp=0x40000c9cf0 pc=0x5557442940
encoding/gob.mustGetTypeInfo(0x55582f1b20, 0x55581d83a0, 0x55582f1b20)
	C:/sdev/Go/src/encoding/gob/type.go:766 +0x28 fp=0x40000c9d90 sp=0x40000c9d40 pc=0x5557446030
	C:/sdev/Go/src/encoding/gob/type.go:259 +0x1bcc fp=0x40000c9e30 sp=0x40000c9d90 pc=0x5557449674
	C:/sdev/Go/src/runtime/proc.go:5414 +0x94 fp=0x40000c9e70 sp=0x40000c9e30 pc=0x5556fbca3c
	C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9eb0 sp=0x40000c9e70 pc=0x5556fbc9f8
	C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9ef0 sp=0x40000c9eb0 pc=0x5556fbc9f8
	C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9f30 sp=0x40000c9ef0 pc=0x5556fbc9f8
	C:/sdev/Go/src/runtime/proc.go:5409 +0x50 fp=0x40000c9f70 sp=0x40000c9f30 pc=0x5556fbc9f8
	C:/sdev/Go/src/runtime/proc.go:190 +0x1d0 fp=0x40000c9fd0 sp=0x40000c9f70 pc=0x5556fb0348
	C:/sdev/Go/src/runtime/asm_arm64.s:1148 +0x4 fp=0x40000c9fd0 sp=0x40000c9fd0 pc=0x5556fde03c

Copy link

@ncw ncw commented May 12, 2020

All the traces have this in


So I would guess it is encoding/gob that is causing the problem.

This suggests a fairly minimal go program to reproduce - can you try that? It should either do nothing or crash 🤞

package main

import (

func main() {
	var network bytes.Buffer
	_ = gob.NewEncoder(&network)

Copy link

@hyangah hyangah commented May 12, 2020

This happened in android/arm64 but I am not sure if this is a mobile-platform specific issue based on the stack trace (failure while retrieving runtime&reflect type info). Calling runtime experts for help.

/cc @aclements @rsc @randall77 @ianlancetaylor

@hyangah hyangah removed the mobile label May 12, 2020
Copy link

@ianlancetaylor ianlancetaylor commented May 12, 2020

I don't see anything here that seems specific to the mobile platform. I don't know what is happening here.

If someone has a reproduction that doesn't require any special setup or hardware, I imagine that this could be fixed easily.

I agree that doing a git bisect would help.

Copy link
Contributor Author

@x0b x0b commented May 14, 2020

Unfortunately, the test program provided by @ncw does not trigger the bug.

I also tried finding a QEMU image that reproduces the issue, but unfortunately, there does not seem to be an Android 6 arm64-v8a image, and images of newer versions don't show the behavior.

I also tried to reduce rclone to only the bug-producing parts, but my go knowledge is not up to that task. Would it be possible to inject tons of print style debugging messages into rclone? That would be retrievable without special tooling by the user.

Copy link

@ncw ncw commented May 14, 2020

Unfortunately, the test program provided by @ncw does not trigger the bug.


I also tried finding a QEMU image that reproduces the issue, but unfortunately, there does not seem to be an Android 6 arm64-v8a image, and images of newer versions don't show the behavior.

But you've got hardware which can reproduce the problem?

I also tried to reduce rclone to only the bug-producing parts, but my go knowledge is not up to that task. Would it be possible to inject tons of print style debugging messages into rclone? That would be retrievable without special tooling by the user.

We know just where it is going wrong, that is in the traceback so I don't think prints will help.

The best thing to do now would be to git bisect the go compiler.

So check out the go source. Compile it. Build an rclone with that compiler and test it. You then tell git whether that worked or not and git finds another commit to try. I've done it loads of times with the go source. It builds quickly so it doesn't take too long. I'm sure there are lots of tutorials out there to help with the git bisect process. There is even a script in the bin directory in the rclone source which can automate the process assuming you can automate the testing of the rclone binary on the phone

The result will be the commit that broke the rclone compile and that will probably be enough for the team to figure out what is going on.

Copy link
Contributor Author

@x0b x0b commented May 14, 2020

But you've got hardware which can reproduce the problem?

No, otherwise I would have bisected it right away. I have to send a test package to an affected user, who then has to execute the package and report the results back.

I did modify gvm in a way to mass-build your test from source with for every possible golang version, but until we have a test program that crashes, mass building would be a waste of resources. And mass-building rclone itself is not really feasible.

However, I just had an idea and looked through old Google Play prelaunch reports - it does seem that Firebase has affected devices in their device farm. If it checks out, it might be possible to build an APK that can act as remote verifier. It will take a few days to build and test that.

Copy link
Contributor Author

@x0b x0b commented May 18, 2020

The prelaunch idea worked out. I used a Huawei P8 Lite from Firebase as proxy device since it shows the same behaviour - and test data from the affected user confirms it as well.

The bisect result is this commit: d3c2b1f

d3c2b1f17600fadeebf62d65c85baf3bef879e2b is the first bad commit
commit d3c2b1f17600fadeebf62d65c85baf3bef879e2b
Author: Elias Naur <>
Date:   Wed Nov 13 11:57:17 2019 +0100

    cmd/link/internal/ld,misc/cgo/testcshared: don't -fuse-ld=gold on Android

    The NDK is switching to ldd, and will stop including the gold linker.

    Change-Id: If74168017c9874134b34010906ab1d94001528b6
    TryBot-Result: Gobot Gobot <>
    Reviewed-by: Ian Lance Taylor <>

 misc/cgo/testcshared/cshared_test.go | 2 +-
 src/cmd/link/internal/ld/lib.go      | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Mentioning that in the official 1.14 changelog would have saved me a few days 🙄, especially since lld is still in testing as of the latest ndk release. Consequently, adding -fuse-ld=gold back via env vars fixes the issue on >= d3c2b1f, including go 1.14.x.

ianlancetaylor 2020-05-12T19:02:47Z
If someone has a reproduction that doesn't require any special setup or hardware, I imagine that this could be fixed easily.

We aren't 100% there, but with Firebase, I managed to confirm a working/breaking version in about 10 minutes/version. According to the play catalogue, filtered to Android 5.0-6.0.1 arm64-v8a, >1200 devices should be affected by this, so it is not all that unlikely that you actually have affected hardware somewhere in your drawer.

Anyway, I can now confirm that go is broken when cross-compiling rclone v1.51.0 using Android NDK 20b, clang, lld for both Android 5.0 and 6.0.1 on aarch64.

Copy link

@hyangah hyangah commented May 18, 2020

awesome, @x0b!

@eliasnaur @ianlancetaylor is it possible to revert the change (in particular, if ldd is still under testing)?

Copy link

@ianlancetaylor ianlancetaylor commented May 18, 2020

I'm fine with reverting the change. I don't know anything about this.

@x0b Thanks for the nice investigation of the problem.

Copy link

@eliasnaur eliasnaur commented May 18, 2020

I suppose the change can be reverted, with the caveat that the Corellium virtual Androids may not have gold installed.

I wonder why @steeve is not affected by similar crashes (or perhaps he is?).

FWIW, ldd has been available since NDK r18b from late 2018, and "AOSP has switched to using LLD by default". Are you affected by android/ndk#843, @xob?

Copy link

@steeve steeve commented May 18, 2020

We are not affected.

Maybe it's because we are still running 1.13.8 + NDK 18b.

We are also building with Bazel 2.0, which doesn't use lld on NDK18b (which at the time was experimental and opt-in).

Copy link

@eliasnaur eliasnaur commented May 18, 2020

Hang on, are you sure you're running lld and not just the linker that prompted the explicit -fuse-ld=gold in the first place (ld?)? In particular, if you explicitly set -fuse-ld=lld does your program still crash? If not, I think that's a better option.

Copy link
Contributor Author

@x0b x0b commented May 19, 2020

You're right, more test data was needed.

Regarding android/ndk#843 (default, I did those tests before reading the second comment):

Test Gradle Stripped Non-Stripped
d3c2b1f FAIL FAIL

Regarding linker parameter (-fuse-ld=?, on NDK 21.1 / latest):

Test gold (default) lld
d3c2b1f OK FAIL OK

So the conclusion is...the NDK default is neither of those options.

I guess the best thing would be to switch to explicit lld, which should continue to work when NDK switches to lld as default.

Copy link

@eliasnaur eliasnaur commented May 19, 2020

I guess the best thing would be to switch to explicit lld, which should continue to work when NDK switches to lld as default.

I agree. Can you prepare a CL?

Copy link
Contributor Author

@x0b x0b commented May 19, 2020

I can try. I need some time to verify if any lld version is good and when to try to fall back to gold though.

Copy link

@gopherbot gopherbot commented May 22, 2020

Change mentions this issue: src/cmd/link/internal/ld/lib.go: use ldd or gold on Android

Copy link

@gopherbot gopherbot commented May 25, 2020

Change mentions this issue: env/android-amdn64-emu: upgrade NDK to version 21.1.6352462

Copy link

@gopherbot gopherbot commented May 25, 2020

Change mentions this issue: cmd/link/internal/ld: consider alternative linkers in linkerFlagSupported

gopherbot pushed a commit that referenced this issue May 25, 2020

CL 235017 is about to change the default Android linker to lld. lld doesn't
support the --compress-debug-sections=zlib-gnu flag, but linkerFlagSupported
doesn't take any alternative linkers specified with -fuse-ld into account.

Updates #38838

Change-Id: I5f7422c06d40dedde2e4b070fc48398e8f822190
Run-TryBot: Elias Naur <>
TryBot-Result: Gobot Gobot <>
Reviewed-by: Ian Lance Taylor <>
@golang golang locked and limited conversation to collaborators May 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
arch-arm64 FrozenDueToAge NeedsInvestigation OS-Android
None yet

Successfully merging a pull request may close this issue.

8 participants