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: unexpected return pc for runtime.sigtramp on darwin/arm64 builder #29305

Closed
eliasnaur opened this issue Dec 17, 2018 · 1 comment
Closed

Comments

@eliasnaur
Copy link
Contributor

From https://build.golang.org/log/93c24b649dcf7c5e192159c4ab4288094a7a0582:

...
##### GOMAXPROCS=2 runtime -cpu=1,2,4 -quick
lldb: running program
fatal error: unexpected signal during runtime execution
panic during panic
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x10067f0a4]

goroutine 0 [idle]:
runtime.throw(0x10090755a, 0x2a)
	/private/var/folders/qq/qxn86k813bn9fjxydm095rxw0000gp/T/workdir-host-darwin-amd64-zenly-ios/go/src/runtime/panic.go:608 +0x4c fp=0x130011d10 sp=0x130011ce0 pc=0x10067ed64
runtime.sigpanic()
	/private/var/folders/qq/qxn86k813bn9fjxydm095rxw0000gp/T/workdir-host-darwin-amd64-zenly-ios/go/src/runtime/signal_unix.go:374 +0x43c fp=0x130011d40 sp=0x130011d10 pc=0x100693194
runtime.gcWriteBarrier(0x0, 0x100691eb4, 0x0, 0x130000000, 0x0, 0x100692b44, 0x3, 0x0, 0x0, 0x0, ...)
	/private/var/folders/qq/qxn86k813bn9fjxydm095rxw0000gp/T/workdir-host-darwin-amd64-zenly-ios/go/src/runtime/asm_arm64.s:1165 +0x14 fp=0x130011e40 sp=0x130011d50 pc=0x1006ac9dc
runtime.startpanic_m(0x3)
	/private/var/folders/qq/qxn86k813bn9fjxydm095rxw0000gp/T/workdir-host-darwin-amd64-zenly-ios/go/src/runtime/panic.go:747 +0x11c fp=0x130011e70 sp=0x130011e40 pc=0x10067f0a4
runtime.sighandler(0x100000003, 0x16f7aeac0, 0x16f7aeb28, 0x100b4e8a0)
	/private/var/folders/qq/qxn86k813bn9fjxydm095rxw0000gp/T/workdir-host-darwin-amd64-zenly-ios/go/src/runtime/signal_sighandler.go:100 +0x510 fp=0x130011f20 sp=0x130011e70 pc=0x1006922c8
runtime.sigtrampgo(0x3, 0x16f7aeac0, 0x16f7aeb28)
	/private/var/folders/qq/qxn86k813bn9fjxydm095rxw0000gp/T/workdir-host-darwin-amd64-zenly-ios/go/src/runtime/signal_unix.go:351 +0x1bc fp=0x130011fd0 sp=0x130011f20 pc=0x100692b44
runtime: unexpected return pc for runtime.sigtramp called from 0x0
stack: frame={sp:0x130011fd0, fp:0x130012060} stack=[0x130002000,0x130012000)
0000000130011ed0:  0000000000000000  0000000130000000 
0000000130011ee0:  0000000000000000  000000010088adc0 
0000000130011ef0:  000000010090c620  000000010088adc0 
0000000130011f00:  000000010090c620  000000016f7aeac0 
0000000130011f10:  000000016f7aeb28  0000000000000000 
0000000130011f20:  00000001006ad0dc <runtime.sigtramp+164>  0000000100000003 
0000000130011f30:  000000016f7aeac0  000000016f7aeb28 
0000000130011f40:  0000000100b4e8a0  0000000000000000 
0000000130011f50:  0000000000000000  0000000000000000 
0000000130011f60:  0000000000000000  0000000000000000 
0000000130011f70:  0000000000000000  0000000000000000 
0000000130011f80:  0000000100b4e8a0  0000000000000000 
0000000130011f90:  0000000000000000  0000000000000000 
0000000130011fa0:  0000000000000000  0000000000000000 
0000000130011fb0:  0000000000000000  0000000000000000 
0000000130011fc0:  0000000000000000  0000000000000000 
0000000130011fd0: <0000000000000000  0000000000000003 
0000000130011fe0:  000000016f7aeac0  000000016f7aeb28 
0000000130011ff0:  000000016f7aea10  0000000000000000 
runtime.sigtramp(0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/private/var/folders/qq/qxn86k813bn9fjxydm095rxw0000gp/T/workdir-host-darwin-amd64-zenly-ios/go/src/runtime/sys_darwin_arm64.s:206 +0xa4 fp=0x130012060 sp=0x130011fd0 pc=0x1006ad0dc
...

I failed to find an open issue for the crash.

@ianlancetaylor
Copy link
Contributor

I would guess that the "unexpected return PC" is because the traceback code is getting confused by the switch to the gsignal stack in runtime.sigtramp in runtime/sys_darwin_arm64.s.

But there is a deeper problem which is that we should not have called gcWriteBarrier, which is what led to the traceback crash. The signal handler code should have a valid G and M, but it need not have a valid P. The call to gcWriteBarrier is only OK if there is a valid P. Since sighandler calls startpanic_m, startpanic_m can't have any write barriers. But it does.

So this is an actual occurrence of #26575, which I think I previously deduced just by reading the code. Closing this issue as a dup.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants