go1.8rc1 && master on darwin
Sending a SIGINT to a go build ./... caused a runtime error:
go build ./...
signal 2 received on thread with no signal stack
fatal error: non-Go code disabled sigaltstack
runtime.sigtrampgo(0x2, 0xc4207fcd10, 0xc4207fcd78)
runtime.sigtramp(0xc420114386, 0x5, 0x5956, 0x200005a00000085, 0xc4202f43a0, 0x0, 0xe, 0xc4207fce30, 0x0, 0x3, ...)
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
/cc @rsc @ianlancetaylor
Which version of Darwin?
Is there any more to that stack trace? Please try setting the environment variable GOTRACEBACK=system when running go build.
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.
I've looked over the Go runtime code, and it looks fine.
@quentinmit Is it still possible to ssh into that Sierra system?
@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?
@quentinmit, nope. running vanilla macOS on real hardware.
"haxies" = things that inject code into running programs; Application Enhancer and SIMBL are examples of that.
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.