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: testtls segmentation fault on a linux-arm builder #24758

Open
mvdan opened this Issue Apr 7, 2018 · 6 comments

Comments

Projects
None yet
5 participants
@mvdan
Member

mvdan commented Apr 7, 2018

fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x1b pc=0xe56e4]

runtime stack:
runtime.throw(0x16739f, 0x2a)
	/workdir/go/src/runtime/panic.go:598 +0x54
runtime.sigpanic()
	/workdir/go/src/runtime/signal_unix.go:372 +0x22c

goroutine 5 [syscall, locked to thread]:
runtime.cgocall(0xe5678, 0x429f78, 0xe5208)
	/workdir/go/src/runtime/cgocall.go:128 +0x64 fp=0x429f60 sp=0x429f48 pc=0x123c0
_/workdir/go/misc/cgo/testtls._Cfunc_getTLS(0x0)
	_cgo_gotypes.go:43 +0x38 fp=0x429f74 sp=0x429f60 pc=0xe5134
_/workdir/go/misc/cgo/testtls.testTLS(0x478120)
	/workdir/go/misc/cgo/testtls/tls.go:21 +0x34 fp=0x429fb0 sp=0x429f74 pc=0xe5214
_/workdir/go/misc/cgo/testtls.TestTLS(0x478120)
	/workdir/go/misc/cgo/testtls/tls_test.go:12 +0x1c fp=0x429fb8 sp=0x429fb0 pc=0xe50ec
testing.tRunner(0x478120, 0x168c34)
	/workdir/go/src/testing/testing.go:791 +0xac fp=0x429fe4 sp=0x429fb8 pc=0xb3074
runtime.goexit()
	/workdir/go/src/runtime/asm_arm.s:840 +0x4 fp=0x429fe4 sp=0x429fe4 pc=0x63184
created by testing.(*T).Run
	/workdir/go/src/testing/testing.go:838 +0x240

goroutine 1 [runnable]:
testing.(*T).Run(0x478120, 0x1604a5, 0x7, 0x168c34, 0x410540)
	/workdir/go/src/testing/testing.go:839 +0x260
testing.runTests.func1(0x478090)
	/workdir/go/src/testing/testing.go:1081 +0x50
testing.tRunner(0x478090, 0x44bef8)
	/workdir/go/src/testing/testing.go:791 +0xac
testing.runTests(0x40c040, 0x206598, 0x1, 0x1, 0x458100)
	/workdir/go/src/testing/testing.go:1079 +0x21c
testing.(*M).Run(0x458100, 0x0)
	/workdir/go/src/testing/testing.go:996 +0x134
main.main()
	_testmain.go:42 +0x12c
exit status 2
FAIL	_/workdir/go/misc/cgo/testtls	0.046s

Some recent occurences:

https://build.golang.org/log/b7e1728e48a73089be64d42ea3b7e581eeae029c
https://build.golang.org/log/56a9b6b774c15433baff5b11a2f2eeb8aaa936a1

@mvdan mvdan added the Testing label Apr 7, 2018

@josharian

This comment has been minimized.

Contributor

josharian commented Apr 7, 2018

cc @FiloSottile

Thanks for filing bugs for the flaky tests, @mvdan. Hope we get back to a stable dashboard soon.

@FiloSottile

This comment has been minimized.

Member

FiloSottile commented Apr 7, 2018

This is not my kind of TLS ;) it's Thread Local Storage.

@josharian

This comment has been minimized.

Contributor

josharian commented Apr 7, 2018

Hahaha. Oops. :P

cc @bcmills @ianlancetaylor

@cherrymui

This comment has been minimized.

Contributor

cherrymui commented Apr 10, 2018

The faulting PC, 0xe56e4, is in C code getTLS:

TEXT getTLS(SB) 
  :0                    0xe56d0                 e59f0014                MOVW 0x14(R15), R0      
  :0                    0xe56d4                 e92d4010                PUSH [R4,R14]           
  :0                    0xe56d8                 e08f0000                ADD R0, R15, R0         
  :0                    0xe56dc                 fa001a0a                BLX 0xebf0c             // __tls_get_addr
  :0                    0xe56e0                 e59f3008                MOVW 0x8(R15), R3       
  :0                    0xe56e4                 e7930000                MOVW (R3)(R0), R0       // <--- faulting PC
  :0                    0xe56e8                 e8bd8010                POP [R4,R15]            
  :0                    0xe56ec                 00120938                AND.S.EQ R8>>R9, R2, R0 
  :0                    0xe56f0                 0000001c                AND.EQ R12<<R0, R0, R0  

Here, we just loaded R3=0x1c from the constant pool. The faulting address is 0x1b, which means R0=-1, which means __tls_get_addr returned -1. I haven't looked into what could cause it. Maybe the TLS was not initialized correctly?

@ianlancetaylor ianlancetaylor added this to the Go1.11 milestone Apr 18, 2018

@ianlancetaylor ianlancetaylor changed the title from cmd/dist: testtls segmentation fault on a linux-arm builder to runtime: testtls segmentation fault on a linux-arm builder Jun 14, 2018

@ianlancetaylor

This comment has been minimized.

@ianlancetaylor ianlancetaylor modified the milestones: Go1.11, Go1.12 Jul 10, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment