Comment 1:

Is it really executing Go code in Gsyscall status? The scheduler code is allowed to run
as long as it is not doing things to pointers.

Labels changed: added priority-later, removed priority-triage.

Status changed to Accepted.

Comment 2:

It is. It executes the defer handlers. The problem is that the signal handler does not
check Gsyscall status, and if the goroutine is in Gsyscall it does not try to "acquire
the CPU" to run Go code onto.

Comment 3:

Labels changed: added go1.1.

Comment 4:

I think we may need to crash the program if cgo code gets a synchronous signal.  I think
the only other plausible alternative would be to throw an exception in the signal
handler and catch it in some new function invoked by asmcgocall, but that would add even
more overhead to every cgo call for a very minimal benefit.  Anything else seems like it
might leave the non-Go code in an inconsistent state.

Comment 5:

Well, the crash is roughly what happens now.
Can't we mimic the second part of cgocall() in the signal handler (entersyscall(),
unlock the goroutine, unregister defer if required) and then handle signal as usual
(execute defers and potentially recover)?

Comment 6:

We could do that, but it would mean that the non-Go code would have no chance to do any
cleanups.  In the general case it might be left holding locks, not freeing memory, etc. 
I don't think it's a good idea to simply assume that the non-Go code is OK after a
synchronous signal and to just keep running the program.  I think we could assume that
it is OK if we throw a signal, since that will run any destructors; I don't think we
could assume it is OK if we don't do that.

Comment 7:

I agree: a sync signal (SIGSEGV etc) to C++ must kill the program.

Comment 8:

It's still required to kill it reliably (not call defers, not run concurrently with GC).
It's required to check that sigprof/sigqueue do not do allocations, and perhaps add
warning comments.
And there is also related issue that crash in cgo produces misleading crash reports:
https://golang.org/issue/3797

Comment 9:

OK, while I am looking at sigqueue :)
https://golang.org/issue/4383

Comment 10:

Labels changed: added size-l.

Comment 11:

This issue was closed by revision b0a29f3.

Status changed to Fixed.