runtime/cgo: test signal from foreign thread before cgo call

[crawshaw]

A C++ program can trigger the Go signal handler from a global constructor before any cgo calls are made. As badsignal uses cgocallback, this requires an extra M be initialized. This was done for #10207, as it appears to sometimes happen with the os/signal tests on darwin/arm.

It needs a robust test.

There also needs to be some decision made about how this interacts with the deadlock detector. (Perhaps another issue.)

/cc @dvyukov

[dvyukov]

Does the signal happen in a global ctor? Or in a thread created by a global ctor?
I would expect that it is the latter. Because if it happens in a global ctor (in the main thread), then if a signal is delivered before Go runtime is initialized, then it also has not setup own signal handlers, thus badsignal won't be invoked; if it happens after runtime initialization, then the main thread also has a valid g/m, thus badsignal won't be invoked as well.

[crawshaw]

I assume in a foreign thread created by a global ctor. But I'm diagnosing from afar without code.

[dvyukov]

Maybe we want to split notion of extram's and disabled deadlock detection then? E.g. allow to have spare extram's but don't disable deadlock detection? And then create the first extram in schedinit, but disable deadlock detection on the first cgocall.

[ianlancetaylor]

It seems to me that we should disable deadlock detection if a program has any functions exported by cgo.

[minux]

static constructor creates threads, and signals are delivered to those threads. As those threads don't have g, sigtramp will call badsignal, which uses cgocallback. For #10207, I suspect the foreign thread is the one for the task debug port, so we should block every signal in that thread and try again without the original fix. Another fix is that in badsignal, if exteram is not available, see if the signal can be ignored, if so, just return; otherwise print a message and exit.

[ianlancetaylor]

Yes, sigsend does nothing if sig.inuse is false, so one quick way to avoid many problems is for badsignal to do nothing in that case. It's not a real solution, though.

[dvyukov]

@minux, it all sounds good, except for the very last part.
Signals are generally delivered to a random thread. Consider that an app registers a handler for SIGUSR1, and a user sends it from a console to update config or something. Now, once in a while the app just crashes (when the signal got delivered to that external thread) instead of processing the signal.

But I am curious whether the rest of what you proposed will fix the original problem or not.

[minux]

The last part is essentially what will happen today (before the fix to #10207). If we want deadlock detection, then we can't start extram until the first cgo call, and if we don't have extram, we can't deliver the received signal if it's received on the foreign thread. What's more, we can't ignore the signal, because the user program might be waiting for that signal. The best thing we can do is to crash as before ("cgocallback before cgo call"). The best way to fix this is to make badsignal do the signal delivery without cgocallback.

[rsc]

We fixed #10139, which I think was important for Go 1.5. I don't believe this one is as important. It can likely wait until Go 1.6, although it's subtle enough it should be done early in the cycle.

[rsc]

Rereading this thread, I'm completely lost. Can someone give a clear statement of the problem? (What did you do? What happened? What did you expect instead?)

If not, let's close this bug.

[ianlancetaylor]

Not to speak for @crawshaw, but I think this issue is really just about adding a test. As far as I can see the current code works.

See the lengthy discussion at the end of https://golang.org/cl/7978 .