runtime: signal 2 received on thread with no signal stack #18600

Open
jbardin opened this Issue Jan 10, 2017 · 8 comments

Projects

None yet

4 participants

@jbardin
Contributor
jbardin commented Jan 10, 2017

go1.8rc1 && master on darwin

Sending a SIGINT to a go build ./... caused a runtime error:

signal 2 received on thread with no signal stack
fatal error: non-Go code disabled sigaltstack

runtime stack:
runtime.throw(0x1499cf6, 0x20)
	/usr/local/go/src/runtime/panic.go:596 +0x95
runtime.noSignalStack(0x2)
	/usr/local/go/src/runtime/signal_unix.go:455 +0x94
runtime.sigtrampgo(0x2, 0xc4207fcd10, 0xc4207fcd78)
	/usr/local/go/src/runtime/signal_unix.go:238 +0x2d8
runtime.sigtramp(0xc420114386, 0x5, 0x5956, 0x200005a00000085, 0xc4202f43a0, 0x0, 0xe, 0xc4207fce30, 0x0, 0x3, ...)
	/usr/local/go/src/runtime/sys_darwin_amd64.s:240 +0x28

Managed to replicate this by building in a fairly large project, and running for a while

$ while true; do go build ./...& sleep .$RANDOM; kill -2 %; done
@bradfitz
Member
@bradfitz bradfitz added this to the Go1.8Maybe milestone Jan 10, 2017
@ianlancetaylor
Contributor

Which version of Darwin?

Is there any more to that stack trace? Please try setting the environment variable GOTRACEBACK=system when running go build.

@jbardin
Contributor
jbardin commented Jan 11, 2017

Sorry, running on macOS 10.12.2 (16C67)

Here's a full system stack trace: https://gist.github.com/jbardin/0421e4a7689ebc46732894f3f8e2af8d

I wasn't able to trigger it on Linux, but I may also just be missing the timing window on that machine.

@ianlancetaylor
Contributor

I've looked over the Go runtime code, and it looks fine.

@quentinmit Is it still possible to ssh into that Sierra system?

@quentinmit
Contributor

@ianlancetaylor Yeah, I don't remember what we had actually set up though. Ping me on Hangouts and I can set it up again.

@jbardin Do you have any antivirus software installed? Or haxies?

@jbardin
Contributor
jbardin commented Jan 17, 2017

@quentinmit, nope. running vanilla macOS on real hardware.

@quentinmit
Contributor

"haxies" = things that inject code into running programs; Application Enhancer and SIMBL are examples of that.

@jbardin
Contributor
jbardin commented Jan 17, 2017

Not running anything like that that I know of, unless macOS is injecting something by default.

I did see that the go tool is dynamically linked, so as an experiment I rebuilt the toolchain with CGO_ENABLED=0 and haven't been able to reproduce the crash. I'm not able to reliably reproduce the crash in the first place though, so this doesn't prove anything, just adds another data point.

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